管理および設定ガイド
Red Hat JBoss Data Grid 6 を設定および管理するためのガイド
エディッション 1
Darrin Mison
概要
前書き
第1章 JBoss Data Grid
1.1. JBoss Data Grid について
- スキーマレスなキーバリューストア – Red Hat JBoss Data Grid は、固定のデータモデルを用いずに異なるオブジェクトを格納するフレキシブルな NoSQL データベースです。
- グリッドベースのデータストレージ – Red Hat JBoss Data Grid は、複数のノードにまたがったデータのレプリケートが簡単に行えるよう設計されています。
- エラスティックスケーリング – シンプルに混乱を起こさずノードの追加と削除を行えます。
- 複数のアクセスプロトコル – REST、Memcached、Hot Rod または簡単なマップのような API を使用して簡単にデータグリッドへアクセスできます。
1.2. JBoss Data Grid の使用モード
- リモートクライアントサーバーモード
- リモートクライアントサーバーモードは、管理分散されたクラスター化可能なデータグリッドサーバーを提供します。アプリケーションは Hot Rod、Memcached、または REST クライアント API を使用して、データグリッドにリモートアクセスできます。
- ライブラリーモード
- ライブラリーモードは、カスタムランタイム環境の構築やデプロイに必要なすべてのバイナリを提供します。ライブラリー使用モードでは、分散クラスターの 1 つのノードへローカルアクセスでできます。この使用モードでは、使用されるコンテナの仮想マシン内でアプリケーションがデータグリッドの機能にアクセスできます。サポート対象のコンテナには、Tomcat 7 や JBoss Enterprise Application Platform 6 などがあります。
1.3. JBoss Data Grid の利点
JBoss Data Grid の利点
- 巨大なヒープと高可用性
- JBoss Data Grid では、パフォーマンス向上のためにアプリケーションがデータのルックアップ処理のほとんどを大型のサーバーデータベースへ委譲する必要がありません。JBoss Data Grid は、現在のエンタープライズアプリケーションの大部分に存在するボトルネックを完全に取り除きます。
例1.1 巨大なヒープと高可用性の例
100 個のブレードサーバーを持つグリッドの例として、各ノードがレプリケートされたキャッシュ専用の 2 GB のストレージ領域を持っているとします。この場合、グリッドの全データが 2 GB のデータのコピーとなります。逆に、分散グリッド (データ項目ごとに 1 つのコピーが必要であることを仮定した場合) では、メモリーがサポートする仮想ヒープに 100 GB のデータが含まれます。グリッドのどこからでも効果的にこのデータへアクセスできるようになります。サーバーに障害が発生した場合、グリッドによって損失データの新しいコピーが即座に作成され、グリッドの運用サーバーに置かれます。 - スケーラビリティー
- JBoss Data Grid ではデータが均一に分散されるため、グリッドサイズの唯一の上限はネットワーク上でのグループ通信になります。ネットワークのグループ通信は最小限で、新規ノードの発見のみに制限されています。すべてのデータアクセスパターンは、ノードによるピアツーピア接続を介した直接通信を許可するため、スケーラビリティーの更なる向上を容易にします。JBoss Data Grid のクラスターは、リアルタイムでスケールアップまたはスケールダウンすることが可能ですが、インフラストラクチャーの再起動を必要としません。スケーリングポリシーへの変更をリアルタイムで適用できるため、非常にフレキシブルな環境を実現することができます。
- データ分散
- JBoss Data Grid は一貫したハッシュアルゴリズムを使用して、クラスターにおけるキーの場所を判断します。一貫したハッシュに関する利点には次のようなものがあります。データ分散は、永続性とフォールトトラレンスを提供するため、余分のない十分なコピーがクラスター内に確実に存在するようにします。余分なコピーは環境のスケーラビリティーを低下させます。
- コスト効果
- 速度
- 更なるメタデータやネットワークトラフィックの必要がない、決定論的なキーの場所
- 永続性
- JBoss Data Grid は、
CacheStore
インターフェースと複数の高パフォーマンス実装 (JDBC キャッシュストアやファイルシステムベースのキャッシュストアなど) を公開します。キャッシュストアはキャッシュをシードし、関連データを安全に保持し、破損しないようにします。また、キャッシュストアはプロセスがメモリー不足になると、データをディスクへオーバーフローします。 - 言語のバインディング
- JBoss Data Grid は、既に多くの一般的なプログラミング言語向けに使用されている Memcached プロトコルと、Hot Rod と呼ばれる最適化された JBoss Data Grid 固有のプロトコルの両方をサポートします。そのため、Java Data Grid は Java に限定されず、すべての主要な Web サイトやアプリケーションに使用できます。
- 管理
- 数百個またはそれ以上のサーバーが存在するグリッド環境では、管理の実行は重要な機能になります。エンタープライズネットワーク管理ソフトウェアである JBoss Operations Network は、複数の JBoss Data Grid インスタンスを管理するのに最適なツールです。JBoss Operations Network の機能を使用すると、キャッシュマネージャーやキャッシュインスタンスを簡単かつ効率的に監視できます。
1.4. JBoss Data Grid の前提条件
1.5. JBoss Data Grid のバージョン情報
1.6. JBoss Data Grid のキャッシュアーキテクチャー
図1.1 JBoss Data Grid のキャッシュアーキテクチャー
- ユーザーが直接対話できない要素 (背景が灰色の部分)。これにはキャッシュ、キャッシュマネージャー、1 次キャッシュ、永続ストアインターフェース、永続ストアなどが含まれます。
- ユーザーが直接対話できる要素 (背景が白の部分)。これにはキャッシュインターフェースやアプリケーションなどが含まれます。
JBoss Data Grid のキャッシュアーキテクチャーには次の要素が含まれます。
- キャッシュインスタンスやエントリーを永久的に格納する永続ストア。
- JBoss Data Grid は、永続ストアのアクセスに 2 つの永続ストアインターフェースを提供します。永続ストアインターフェースは以下のいずれかになります。
- キャッシュローダーは永続データストアへの接続を提供する読み取り専用インターフェースです。キャッシュローダーは、キャッシュインスタンスおよび永続ストアよりデータの場所を見つけ、読み出すことができます。詳細は 「キャッシュローダー」 を参照してください。
- キャッシュストアは、キャッシュローダーによるステートのロードおよび格納を許可するメソッドを公開し、キャッシュローダーの機能に書き込み機能が含まれるようにします。詳細は 10章キャッシュストアとキャッシュローダー を参照してください。
- 1 次キャッシュ (L1 キャッシュ) は、リモートキャッシュエントリーが最初にアクセスされた後にそれらのエントリーを格納し、同じエントリーがその後使用される度に不必要なリモートフェッチ操作が行われないようにします。詳細は 14章1 次キャッシュ を参照してください。
- キャッシュマネージャーは JBoss Data Grid のキャッシュインスタンスを読み出すために使用される主なメカニズムで、キャッシュを使用する時の開始点とすることができます。詳細は 11章キャッシュマネージャー を参照してください。
- キャッシュはキャッシュマネージャーによって読み出されたキャッシュインスタンスを格納します。
- キャッシュインターフェースは Memcached や Hot Rod などのプロトコルを使用します。キャッシュを持つインターフェースには REST を使用することもできます。リモートインターフェースに関する詳細は『開発者ガイド』を参照してください。
- Memcached は、データベースドライバー Web サイトの応答時間や操作時間を改善するために使用されるインメモリーキャッシングシステムです。Memcached キャッシングシステムは、Memached プロトコルと呼ばれるテキストベースのクライアントサーバーキャッシングプロトコルを定義します。
- Hot Rod は JBoss Data Grid で使用されるバイナリ TCP クライアントサーバープロトコルです。Memchached などの他のクライアントサーバープロトコルに不足している機能を補うために作成されました。Hot Rod は、パーティション化または分散化された JBoss Data Grid サーバークラスターの要求を、クライアントがスマートルーティングできるようにします。
- REST プロトコルは、密結合のクライアントライブラリおよびバインディングを不要にします。REST API ではオーバーヘッドが発生し、REST 呼び出しの理解と作成に REST クライアントまたはカスタムコードを必要とします。
- アプリケーションは、キャッシュインターフェースを介してユーザーがキャッシュとやりとりできるようにします。このようなエンドユーザーアプリケーションの一般的な例がブラウザーです。
1.7. JBoss Data Grid の API
1.7.1. JBoss Data Grid の API
- キャッシュ
- バッチ処理
- グループ化
- CacheStore
- 外部化
- 非同期 API (リモートクライアントサーバーモードで Hot Rod クライアントを併用する場合のみ使用可能)
- REST インターフェース
- Memcached インターフェース
- Hot Rod インターフェース
- RemoteCache API
1.7.2. 非同期 API について
Async
を追加します。非同期メソッドは、操作の結果が含まれる Future を返します。
Cache(String, String)
とパラメーター化されたキャッシュでは、Cache.put(String key, String value)
は String を返します。また、Cache.putAsync(String key, String value)
は Future(String)
を返します。
1.7.3. バッチ化 API について
注記
1.7.4. キャッシュ API について
ConcurrentMap
インターフェースによって公開されるアトミックメカニズムが含まれます。エントリーが格納される方法は、使用されるキャッシュモードによって異なります。例えば、エントリーがリモートノードへレプリケートされたり、キャッシュストアでルックアップされたりすることもあります。
注記
1.7.5. RemoteCache インターフェースについて
1.8. ツールと操作
1.8.1. 管理ツールについて
関連トピック:
1.8.2. URL 経由のデータアクセス
put()
および post()
メソッドは、キャッシュにデータを格納します。使用される URL より使用されるキャッシュ名とキーを判断することができます。データはキャッシュに格納される値で、要求のボディーに置かれます。
GET
および HEAD
メソッドが使用され、他のヘッダーはキャッシュの設定と挙動を制御します。
注記
1.8.3. Map メソッドの制限
size()
、 values()
、 keySet()
、 entrySet()
など特定の Map
メソッドは不安定であるため、JBoss Data Grid で一定の制限を用いて使用することが可能です。これらのメソッドはロック (グローバルまたはローカル) を取得せず、同時編集、追加および削除はこれらの呼び出しでは考慮されません。さらに、前述のメソッドはローカルのデータコンテナ上でのみ操作可能で、ステートのグローバルビューは提供しません。
第2章 JBoss Data Grid でのロギング
2.1. JBoss Data Grid におけるロギングの概要
2.2. サポート対象のアプリケーションロギングフレームワーク
2.2.1. サポート対象のアプリケーションロギングフレームワーク
- JBoss Data Grid 6 に含まれる JBoss Logging。
2.2.2. JBoss Logging について
2.2.3. JBoss のロギング機能
- 革新的で使いやすい 型指定された ロガーを提供します。
- 国際化および現地化を完全サポートします。翻訳者はプロパティーファイルのメッセージバンドルを使用します。開発者はインターフェースやアノテーションを使用できます。
- 実稼働用の型指定されたロガーを生成し、開発用の型指定されたロガーをランタイムに生成するビルドタイムツール。
2.3. ロギングの設定
2.3.1. ブートロギングについて
2.3.2. ブートロギングの設定
logging.properties
ファイルを編集します。このファイルは標準的な Java プロパティーファイルであるため、テキストエディターで編集することができます。このファイルの各行の形式は property=value
になります。
logging.properties
ファイルは $JDG_HOME/standalone/configuration
フォルダーにあります。
2.3.3. デフォルトのログファイルの場所
表2.1 デフォルトのログファイルの場所
ログファイル | 場所 | 説明 |
---|---|---|
boot.log | $JDG_HOME/standalone/log/ | サーバールートログ。サーバーの起動に関連するログメッセージが含まれます。 |
server.log | $JDG_HOME/standalone/log/ | サーバーログ。サーバー起動後のすべてのログメッセージが含まれます。 |
2.4. ロギング属性
2.4.1. ログレベルについて
TRACE
DEBUG
INFO
WARN
ERROR
FATAL
WARN
レベルのログハンドラーは、WARN
、ERROR
、および FATAL
のレベルのメッセージのみを記録します。
2.4.2. サポートされているログレベル
表2.2 サポートされているログレベル
ログレベル | 値 | 説明 |
---|---|---|
FINEST | 300 | - |
FINER | 400 | - |
TRACE | 400 | アプリケーションの実行状態について詳細な情報を提供するメッセージに使用されます。TRACE レベルが有効な状態でサーバーが実行されている時に TRACE レベルのログメッセージがキャプチャーされます。 |
DEBUG | 500 | 各要求の進捗やアプリケーションのアクティビティを示すメッセージに使用されます。DEBUG レベルが有効な状態でサーバーが実行されている時に DEBUG レベルのログメッセージがキャプチャーされます。 |
FINE | 500 | - |
CONFIG | 700 | - |
INFO | 800 | アプリケーションの全体的な進捗を示すメッセージに使用されます。アプリケーションの起動やシャットダウン、その他の主なライフサイクルイベントに対して使用されます。 |
WARN | 900 | エラーではないが、理想的とは見なされない状況を示すために使用されます。将来的にエラーをもたらす可能性のある状況を示します。 |
WARNING | 900 | - |
ERROR | 1000 | 発生したエラーの中で、現在のアクティビティや要求の完了を妨げる可能性があるが、アプリケーション実行の妨げにはならないエラーを表示するために使用されます。 |
FATAL | 1100 | 重大なサービス障害やアプリケーションのシャットダウンをもたらしたり、JBoss Enterprise Application Platform 6 のシャットダウンを引き起こす可能性があるイベントを表示するのに使用されます。 |
2.4.3. ログカテゴリーについて
DEBUG
ログレベルでは、300
、400
、500
のログの値がキャプチャーされます。
2.4.4. ルートロガーについて
server.log
ファイルに書き込むように設定されています。このファイルはサーバーログと呼ばれる場合もあります。
2.4.5. ログハンドラーについて
Console
File
Periodic
Size
Async
Custom
2.4.6. ログハンドラーのタイプ
表2.3 ログハンドラーのタイプ
ログハンドラーのタイプ | 説明 |
---|---|
コンソール (Console) | コンソールログハンドラーは、ログメッセージをホストオペレーティングシステムの標準出力 (stdout ) または標準エラー (stderr ) ストリームに書き込みます。これらのメッセージは、JBoss Enterprise Application Platform 6 がコマンドラインプロンプトから実行された場合に表示されます。オペレーティングシステムで標準出力または標準エラーストリームをキャプチャーするように設定されていないと、コンソールログハンドラーからのメッセージは保存されません。 |
ファイル (File) | ファイルログハンドラーは最も単純なログハンドラーです。主に、ログメッセージを指定のファイルへ書き込むために使用されます。 |
定期 (Periodic) | 定期ファイルハンドラーは、指定した時間が経過するまで、ログメッセージを指定ファイルに書き込みます。その時間が経過した後は、指定のタイムスタンプがファイル名に追記されます。その後、ハンドラーは元の名前で新規作成されたログファイルに書き込みを継続します。 |
サイズ (Size) | サイズログハンドラーは、指定のファイルが指定サイズに到達するまで、そのファイルにログメッセージを書き込みます。ファイルが指定したサイズに到達すると、名前に数値のプレフィックスを追加して名前変更され、ハンドラーは元の名前で新規作成されたログファイルに書き込みを継続します。各サイズログハンドラーは、このような方式で保管されるファイルの最大数を指定する必要があります。 |
非同期 (Async) | 非同期ログハンドラーは、 単一または複数のログハンドラーを対象とする非同期動作を提供するラッパーログハンドラーです。非同期ログハンドラーは、待ち時間が長かったり、ネットワークファイルシステムへのログファイルの書き込みなどにパフォーマンス上の問題があるログハンドラーに対して有用です。 |
カスタム (Custom) | カスタムログハンドラーにより、実装された新しいタイプのログハンドラーを設定することが可能になります。カスタムハンドラーは、java.util.logging.Handler を拡張する Java クラスとして実装し、モジュール内に格納する必要があります。 |
2.4.7. ログフォーマッターについて
java.util.Formatter
クラスと同じ構文を使用する文字列です。
2.5. ロギング設定プロパティー
2.5.1. ルートロガーのプロパティー
表2.4 ルートロガーのプロパティー
プロパティー | データタイプ | 説明 |
---|---|---|
level | 文字列 |
ルートロガーが記録するログメッセージの最大レベル。
|
handlers | 文字列の一覧 |
ルートロガーによって使用されるログハンドラーの一覧。
|
2.5.2. ログカテゴリーのプロパティ
表2.5 ログカテゴリーのプロパティ
プロパティー | データタイプ | 詳細 |
---|---|---|
level | 文字列 |
ログカテゴリーが記録するログメッセージの最大レベル。
|
handlers | 文字列の一覧 |
ルートロガーによって使用されるログハンドラーの一覧。
|
use-parent-handlers | ブール値 |
true に設定した場合、割り当てられた他のハンドラーだけでなく、ルートロガーのログハンドラーを使用します。
|
category | 文字列 |
ログメッセージがキャプチャーされるログカテゴリー。
|
2.5.3. コンソールログハンドラーのプロパティー
表2.6 コンソールログハンドラーのプロパティー
プロパティー | データタイプ | 説明 |
---|---|---|
level | 文字列 |
ログハンドラーが記録するログメッセージの最大レベル。
|
encoding | 文字列 |
出力に使用される文字エンコーディングスキーム。
|
formatter | 文字列 |
このログハンドラーで使用するログフォーマッター。
|
target | 文字列 |
ログハンドラーの出力先となるシステム出力ストリーム。これは システムエラーストリームの場合は System.err、標準出力ストリームの場合は System.out とすることができます。
|
autoflush | ブール値 |
true に設定すると、ログメッセージは受信直後にハンドラーのターゲットに送信されます。
|
name | 文字列 |
このログハンドラーの一意の ID。
|
2.5.4. ファイルログハンドラープロパティー
表2.7 ファイルログハンドラープロパティー
プロパティー | データタイプ | 詳細 |
---|---|---|
level | 文字列 |
ログハンドラーが記録するログメッセージの最大レベル。
|
encoding | 文字列 |
出力に使用される文字エンコーディングスキーム。
|
formatter | 文字列 |
このログハンドラーで使用するログフォーマッター。
|
append | ブール値 |
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル (すでに存在する場合) に追加されます。false に設定された場合、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。
append に対する変更を反映するには、サーバーを再起動する必要があります。
|
autoflush | ブール値 |
true に設定された場合は、受信直後にハンドラーにより割り当てられたファイルに送信されます。
autoflush に対する変更を反映するには、サーバーを再起動する必要があります。
|
name | 文字列 |
このログハンドラーの一意の ID。
|
file | オブジェクト |
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。このオブジェクトには、
relative-to と path の 2 つの設定プロパティーが含まれます。
|
relative-to | 文字列 |
ファイルオブジェクトのプロパティーであり、ログファイルが書き込まれるディレクトリーです。ここでは、JBoss Enterprise Application Platform 6 のファイルパス変数を指定できます。
jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを示します。
|
path | 文字列 |
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。これは、完全パスを決定するために、
relative-to プロパティーの値に追加されます。
|
2.5.5. 周期ログハンドラープロパティー
表2.8 周期ログハンドラープロパティー
プロパティー | データタイプ | 説明 |
---|---|---|
append | ブール値 |
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル (すでに存在する場合) に追加されます。false に設定された場合、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append に対する変更を反映するには、サーバーを再起動する必要があります。
|
autoflush | ブール値 |
true に設定された場合は、受信直後にハンドラーにより割り当てられたファイルに送信されます。autoflush に対する変更を反映するには、サーバーを再起動する必要があります。
|
encoding | 文字列 |
出力に使用する文字エンコーディングスキーム
|
formatter | 文字列 |
このログハンドラーで使用するログフォーマッター。
|
level | 文字列 |
ログハンドラーが記録するログメッセージの最大レベル。
|
name | 文字列 |
このログハンドラーの一意の ID。
|
file | オブジェクト |
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。このオブジェクトには、
relative-to と path の 2 つの設定プロパティーが含まれます。
|
relative-to | 文字列 |
ファイルオブジェクトのプロパティーであり、ログファイルが書き込まれるディレクトリーです。ここでは、ファイルパス変数を指定できます。
jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを示します。
|
path | 文字列 |
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。完全パスを決定するために、
relative-to プロパティーの値に追加される相対パス名です。
|
suffix | 文字列 |
ローテーションされたログのファイル名に追加され、ローテーションの周期を決定するために使用される文字列です。この接尾辞の形式では、ドット (.) の後に、
java.text.SimpleDateFormat クラスで解析できる日付文字列が指定されます。ログは接尾辞で定義された最小時間単位に基づいてローテーションされます。たとえば、接尾辞が .yyyy-MM-dd の場合は、毎日ログがローテーションされます。
|
2.5.6. サイズログハンドラープロパティー
表2.9 サイズログハンドラープロパティー
プロパティー | データタイプ | 説明 |
---|---|---|
append | ブール値 |
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル (すでに存在する場合) に追加されます。false に設定された場合、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append に対する変更を反映するには、サーバーを再起動する必要があります。
|
autoflush | ブール値 |
true に設定された場合は、受信直後にハンドラーにより割り当てられたファイルに送信されます。autoflush に対する変更を反映するには、サーバーを再起動する必要があります。
|
encoding | 文字列 |
出力に使用する文字エンコーディングスキーム
|
formatter | 文字列 |
このログハンドラーで使用するログフォーマッター。
|
level | 文字列 |
ログハンドラーが記録するログメッセージの最大レベル。
|
name | 文字列 |
このログハンドラーの一意の ID。
|
file | オブジェクト |
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。このオブジェクトには、
relative-to と path の 2 つの設定プロパティーが含まれます。
|
relative-to | 文字列 |
ファイルオブジェクトのプロパティーであり、ログファイルが書き込まれるディレクトリーです。ここでは、ファイルパス変数を指定できます。
jboss.server.log.dir 変数はサーバーの log/ ディレクトリーを示します。
|
path | 文字列 |
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。これは、完全パスを決定するために、
relative-to プロパティーの値に追加されます。
|
rotate-size | 整数 |
ログファイルがローテーションされる前に到達可能な最大サイズ。数字に追加された単一の文字はサイズ単位を示します。バイトの場合は
b 、キロバイトの場合は k 、メガバイトの場合は m 、ギガバイトの場合は g になります。たとえば、50 メガバイトの場合は、50m になります。
|
max-backup-index | 整数 |
保持されるローテーションログの最大数。この数字に達すると、最も古いログが再利用されます。
|
2.5.7. 同期ログハンドラープロパティー
表2.10 同期ログハンドラープロパティー
プロパティー | データタイプ | 詳細 |
---|---|---|
level | 文字列 |
ログハンドラーが記録するログメッセージの最大レベル。
|
name | 文字列 |
このログハンドラーの一意の ID。
|
Queue-length | 整数 |
サブハンドラーが応答するときに、このハンドラーが保持するログメッセージの最大数。
|
overflow-action | 文字列 |
キューの長さを超えたときにこのハンドラーがどのように応答するか。これは
BLOCK または DISCARD に設定できます。BLOCK により、キューでスペースが利用可能になるまでロギングアプリケーションが待機します。これは、非同期でないログハンドラーと同じ動作です。DISCARD により、ロギングアプリケーションは動作し続けますが、ログメッセージは削除されます。
|
subhandlers | 文字列の一覧 |
これは、この非同期ハンドラーがログメッセージを渡すログハンドラーの一覧です。
|
2.6. ロギングの設定例
2.6.1. Root Logger の XML 設定例
<subsystem xmlns="urn:jboss:domain:logging:1.1"> <root-logger> <level name="INFO"/> <handlers> <handler name="CONSOLE"/> <handler name="FILE"/> </handlers> </root-logger> </subsystem>
2.6.2. ログカテゴリーの XML 設定例
<subsystem xmlns="urn:jboss:domain:logging:1.1"> <logger category="com.company.accounts.rec"> <handlers> <handler name="accounts-rec"/> </handlers> </logger> </subsystem>
2.6.3. コンソールログハンドラーの XML 設定例
<subsystem xmlns="urn:jboss:domain:logging:1.1"> <console-handler name="CONSOLE"> <level name="INFO"/> <formatter> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/> </formatter> </console-handler> </subsystem>
2.6.4. ファイルログハンドラーの XML 設定例
<file-handler name="accounts-rec-trail" autoflush="true"> <level name="INFO"/> <file relative-to="jboss.server.log.dir" path="accounts-rec-trail.log"/> <append value="true"/> </file-handler>
2.6.5. 定期ログハンドラーの XML 設定例
<periodic-rotating-file-handler name="FILE"> <formatter> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/> </formatter> <file relative-to="jboss.server.log.dir" path="server.log"/> <suffix value=".yyyy-MM-dd"/> <append value="true"/> </periodic-rotating-file-handler>
2.6.6. サイズログハンドラーの XML 設定例
<size-rotating-file-handler name="accounts_debug" autoflush="false"> <level name="DEBUG"/> <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/> <rotate-size value="500k"/> <max-backup-index value="5"/> <append value="true"/> </size-rotating-file-handler>
2.6.7. 非同期ログハンドラーの XML 設定例
<async-handler name="Async_NFS_handlers"> <level name="INFO"/> <queue-length value="512"/> <overflow-action value="block"/> <subhandlers> <handler name="FILE"/> <handler name="accounts-record"/> </subhandlers> </async-handler>
第3章 サーバーヒンティングを用いた高可用性
3.1. サーバーヒンティングについて
3.2. JGroups によるサーバーヒンティングの確立
関連トピック:
3.3. リモートクライアントサーバーモードでのサーバーヒンティングの設定
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="${jboss.default.jgroups.stack:udp}" > <stack name="udp"> <transport type="UDP" socket-binding="jgroups-udp" site="${jboss.jgroups.transport.site:s1}" rack="${jboss.jgroups.transport.rack:r1}" machine="${jboss.jgroups.transport.machine:m1}"> ... </transport> </stack> </subsystem>
3.4. ライブラリモードでのサーバーヒンティングの設定
<transport clusterName = "MyCluster" machineId = "LinuxServer01" rackId = "Rack01" siteId = "US-WestCoast" />
clusterName
属性はクラスターへ割り当てられた名前を指定します。machineId
属性は、元データを格納する JVM インスタンスを指定します。複数の JVM があるノードや複数の仮想ホストを持つ物理ホストに対して有用な属性です。rackId
パラメーターは、元データが含まれるラックを指定します。これにより、別のラックがバックアップに使用されるようにします。siteId
パラメーターは、相互にレプリケーションを行っている異なるデータセンターのノードを区別します。
第4章 キャッシュモード
4.2. ローカルモード
4.2.1. ローカルモードについて
4.2.2. ローカルモードの操作
- データを永続化するライトスルーおよびライトビハインドキャッシュ。
- Java 仮想マシン (JVM) がメモリー不足にならないようにするためのエントリーエビクション。
- 定義された期間後に期限切れになるエントリーのサポート。
ConcurrentMap
を拡張するため、マップから JBoss Data Grid への移行プロセスが簡単になります。
4.2.3. ローカルモードの設定
<cache-container name="local" default-cache="default" listener-executor="infinispan-listener"> <local-cache name="default" start="EAGER"> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false" /> <transaction mode="NONE" /> </local-cache> </cache-container>
DefaultCacheManager
を作成することもできます。どちらの方法でも、ローカルのデフォルトキャッシュが作成されます。
<transport/>
がない場合はローカルキャッシュのみ格納できます。例で使用されたコンテナには <transport/>
がないため、ローカルキャッシュのみを格納できます。
ConcurrentMap
を拡張し、複数のキャッシュシステムと互換性があります。
4.3. クラスターモード
4.3.1. クラスターモードについて
関連トピック:
4.3.2. クラスターモードの操作
- レプリケーションモードは、クラスターのすべてのキャッシュインスタンスにわたって追加されたエントリーをレプリケートします。
- インバリデーションモードはデータを共有しませんが、無効なエントリーの削除を開始するようリモートキャッシュに伝えます。
- ディストリビューションモードは、クラスターの全ノード上ではなく、ノードのサブセット上の各エントリーを保管します。
4.3.3. 非同期および同期の操作
4.3.4. キャッシュモードのトラブルシューティング
4.3.4.1. ReadExternal の無効なデータ
Cache.putAsync()
を使用する場合、シリアライズを開始するとオブジェクトが変更される可能性があります。それによってデータストリームが破損されると、無効なデータが readExternal
に渡されます。このような場合、オブジェクトへのアクセスを同期化すると、この問題を解決することができます。
4.3.4.2. 非同期通信について
local-cache
によって表され、分散されたモードは distributed-cache
、レプリケートされたモードは replicated-cache
によって表されます。これらの各要素には、mode
プロパティーが含まれ、同期通信の場合は SYNC
、非同期通信の場合は SYNC
に値を設定することができます。
<replicated-cache name="default" start="EAGER" mode="SYNC" batching="false" > ... </replicated-cache>
注記
4.3.4.3. クラスター物理アドレスの読み出し
インスタンスメソッド呼び出しを使用して物理アドレスを読み出すことができます。例えば、AdvancedCache.getRpcManager().getTransport().getPhysicalAddresses()
のように読み出します。
第5章 ディストリビューションモード
5.1. ディストリビューションモードについて
5.2. ディストリビューションモードの一貫したハッシュアルゴリズム
5.3. ディストリビューションモードにおけるエントリーの検索
PUT
操作が実行されると、リモート呼び出しが num_copies
に指定された回数実行されます。クラスターのいずれかのノードでGET
操作が実行されると、リモート呼び出しが 1 回実行されます。バックグラウンドでは、GET
操作が実行されると PUT
操作と同じ回数 (num_copies
パラメーターの値) リモート呼び出しが行われますが、これらの呼び出しは同時に実行され、返されたエントリーは即座に呼び出し側に渡されます。
5.4. ディストリビューションモードの戻り値
5.5. ディストリビューションモードの設定
<cache-container name="local" default-cache="default" listener-executor="infinispan-listener"> <distributed-cache name="default" start="EAGER"> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false" /> <transaction mode="NONE" /> </distributed-cache> </cache-container>
重要
関連トピック:
5.6. 同期および非同期の分散
5.6.1. 同期および非同期の分散について
例5.1 通信モードの例
A
、B
、C
という 3 つのキャッシュがクラスターにあり、キャッシュ A
を B
にマップする K
というキーがあるとします。戻り値の必要なクラスター C
上で、Cache.remove(K)
のような操作を実行するとします。正常に実行するには、操作が最初にキャッシュ A
と B
の両方に呼び出しを同期転送し、キャッシュ A
または B
より返される結果を待つ必要があります。非同期通信が使用された場合、操作が想定通り動作しても戻り値の有用性は保証されません。
5.7. ディストリビューションモードにおける GET および PUT の使用
5.7.1. ディストリビューションモードの GET および PUT 操作について
GET
コマンドを実行します。これは、java.util.Map
コントラクトに従って指定されたキーに関連する以前の値を返すメソッド (Cache.put()
) があるからです。これがキーを所有しないインスタンスで実行され、エントリーが 1 次キャッシュで見つからない場合、PUT
の前にリモートの GET
を実行することが、戻り値を取得するための信頼できる唯一の方法になります。
PUT
操作の前に発生する GET
操作は常に同期になります。
5.7.2. 分散された GET および PUT 操作
PUT
操作を実行する前に、キャッシュが GET
操作を実行することがあります。
GET
操作は同期であるにも関わらず、すべての応答を待たないため、無駄になるリソースが発生します。GET
処理は最初に受信する有効な応答を許可するため、パフォーマンスはクラスターの大きさとは関係ありません。
Flag.SKIP_REMOTE_LOOKUP
フラグを無効にします。
java.util.Map
インターフェースコントラクトに違反します。これは、信頼できず正確でない戻り値が特定のメソッドに提供されるため、コントラクトに違反することになります。そのため、必ずこれらの戻り値が設定上重要な目的に使用されないようにしてください。
第6章 レプリケーションモード
6.1. レプリケーションモードについて
6.2. 最適化されたレプリケーションモードの使用
6.4. レプリケーションモードの設定
<cache-container name="local" default-cache="default" listener-executor="infinispan-listener"> <replicated-cache name="default" start="EAGER"> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false" /> <transaction mode="NONE" /> </replicated-cache> </cache-container>
重要
関連トピック:
6.5. 同期および非同期のレプリケーション
6.5.1. 同期および非同期のレプリケーション
- 同期レプリケーションは、クラスターの全ノードで変更がレプリケートされるまでスレッドや呼び出し側 (
put()
操作の場合) をブロックします。確認応答を待つことで、同期レプリケーションは操作が終了する前にすべてのレプリケーションが正常に適用されるようにします。 - 非同期レプリケーションはノードからの応答を待つ必要がないため、同期レプリケーションよりもかなり高速になります。非同期レプリケーションはバックグラウンドでレプリケーションを実行し、呼び出しは即座に返されます。非同期レプリケーション中に発生したエラーはログに書き込まれます。そのため、クラスターのすべてのキャッシュインスタンスでトランザクションが正常にレプリケートされなくても、トランザクションは正常に終了することが可能です。
6.5.2. 非同期レプリケーションの挙動に対するトラブルシューティング
- ステート転送を無効にし、
ClusteredCacheLoader
を使用して必要な時にリモートステートをレイジーにルックアップします。 - ステート転送と
REPL_SYNC
を有効にします。非同期 API (cache.putAsync(k, v)
など) を使用して「fire-and-forget」機能を有効にします。 - ステート転送と
REPL_ASYNC
を有効にします。PRC はすべて同期的になりますが、レプリケーションキューを有効にすると (非同期モードで推奨) クライアントスレッドは中断されません。
6.6. レプリケーションキュー
6.6.1. レプリケーションキュー
- 以前設定された間隔。
- 要素数を越えるキューサイズ。
- 以前設定された間隔と要素数を越えるキューサイズの組み合わせ。
6.6.2. レプリケーションキューの操作
6.6.3. レプリケーションキューの使用
- 非同期マーシャリングを無効にします。
max-threads
数の値を、transport executor
に対して1
に設定します。transport executor
は次のようにstandalone.xml
で定義されます。<transport executor="infinispan-transport"/>
queue-flush-interval
、値はミリ秒単位) やキューサイズ (queue-size
) と共に次のように設定することができます。
<replicated-cache name="asyncCache" start="EAGER" mode="ASYNC" batching="false" indexing="NONE" queue-size="1000" queue-flush-interval="500"> ... </replicated-cache>
6.7. よくある質問
6.7.1. レプリケーション保証について
6.7.2. 内部ネットワークのレプリケーショントラフィック
IP
アドレスを介したトラフィックにパブリック IP
アドレスを介したトラフィックよりも低い課金を行ったり、内部ネットワークトラフィックにまったく課金しないことがあります ( GoGrid など)。低料金で利用できるよう、内部ネットワークを使用してレプリケーションのトラフィックを転送するよう JBoss Data Grid を設定することが可能です。このような設定では、割り当てられた内部 IP
アドレスを調べるのは簡単ではありませんが、JBoss Data Grid は JGroups インターフェースを使用してこの問題を解決します。
第7章 インバリデーションモード
7.1. インバリデーションモードについて
7.2. インバリデーションモードの使用
7.3. インバリデーションモードの設定
<cache-container name="local" default-cache="default" listener-executor="infinispan-listener"> <invalidated-cache name="default" start="EAGER"> <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false" /> <transaction mode="NONE" /> </invalidated-cache> </cache-container>
重要
関連トピック:
7.4. 同期的 / 非同期的な無効化
- 同期的な無効化は、クラスターのすべてのキャッシュが無効化メッセージを受信し、古いデータをエビクトするまでスレッドをブロックします。
- 非同期的な無効化は、応答待ちのスレッドをブロックせずに無効化メッセージがブロードキャストされる fire-and-forget モードで操作します。
7.5. 1 次キャッシュの無効化
7.5.1. 1 次キャッシュと無効化
第8章 キャッシュ書き込みモード
8.1. ライトスルーおよびライトビハインドキャッシング
- ライトスルー (同期)
- ライトビハインド (非同期)
8.2. ライトスルーキャッシング
8.2.1. ライトスルーキャッシングについて
Cache.put()
呼び出しより)、JBoss Data Grid が基盤のキャッシュストアを見つけ、更新するまで呼び出しが返されないようにします。この機能により、キャッシュストアへの更新をクライアントスレッド境界内で終了させることができます。
8.2.2. ライトスルーキャッシングの利点
8.2.3. ライトスルーキャッシングの設定 (ライブラリモード)
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:infinispan:config:5.0"> <global /> <default /> <namedCache name="persistentCache"> <loaders shared="false"> <loader class="org.infinispan.loaders.file.FileCacheStore" fetchPersistentState="true" ignoreModifications="false" purgeOnStartup="false"> <properties> <property name="location" value="${java.io.tmpdir}" /> </properties> </loader> </loaders> </namedCache> </infinispan>
8.3. ライトビハインドキャッシング
8.3.1. ライトビハインドキャッシングについて
8.3.2. ライトビハインドキャッシングの設定
write-behind
要素をキャッシュストアに追加します。以下は、write-behind
要素をリモートキャッシュストアの設定に追加する例になりますが、他のキャッシュストアタイプの場合でも同様になります。
<remote-store cache="default" socket-timeout="60000" tcp-no-delay="true" fetch-state="false" passivation="true" preload="true" purge="false"> <remote-server outbound-socket-binding="remote-store-hotrod-server" /> <write-behind flush-lock-timeout="1" modification-queue-size="1024" shutdown-timeout="25000" thread-pool-size="1" /> </remote-store>
注記
8.3.3. スケジュール外のライトビハインドストラテジーについて
8.3.4. スケジュール外のライトビハインドストラテジーのライブラリー設定
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:infinispan:config:5.0"> <global /> <default /> <namedCache name="persistentCache"> <loaders shared="false"> <loader class="org.infinispan.loaders.file.FileCacheStore" fetchPersistentState="true" ignoreModifications="false" purgeOnStartup="false"> <properties> <property name="location" value="${java.io.tmpdir}" /> </properties> <async enabled="true" threadPoolSize="10" /> </loader> </loaders> </namedCache> </infinispan>
<async enabled="true" threadPoolSize="10" />
8.3.5. スケジュール外のライトビハインドストラテジーのリモート設定
file-store
要素内に write-behind
を追加すると、スケジュール外のライトビハインドストラテジーの設定がすべてのキャッシュストアに対して許可されます。
<file-store passivation="true" relative-to="temp" path="nc" purge="true" shared="false"> <write-behind flush-lock-timeout="1" modification-queue-size="1024" shutdown-timeout="25000" thread-pool-size="1"/> </file-store>
第9章 ロック
9.1. 楽観的ロックについて
writeSkewCheck
が有効になっている場合、トランザクションが終了する前に、競合する変更が 1 つ以上データに加えられると、楽観的ロックモードのトランザクションはロールバックします。
9.2. 悲観的ロックについて
9.3. 悲観的ロックのタイプ
- 明示的な楽観的ロックは、JBoss Data Grid Lock API を使用してトランザクションの間キャッシュユーザーがキャッシュキーを明示的にロックできるようにします。ロック呼び出しは、クラスターの全ノードにおいて、指定されたキャッシュキー上でロックの取得を試みます。ロックはすべてコミットまたはロールバックフェーズ中に開放されます。
- 暗黙的な悲観的ロックは、キャッシュキーが変更操作のためアクセスされる時にキャッシュキーがバックグラウンドでロックされるようにします。暗黙的な悲観的ロックを使用すると、各変更操作に対してキーが確実にローカルでロックされるよう JBoss Data Grid がチェックします。ロックされていないキャッシュキーが見つかると、JBoss Data Grid はロックされていないキャッシュキーのロックを取得するため、クラスターワイドのロックを要求します。
9.4. 明示的な悲観的ロックの例
tx.begin() cache.lock(K) cache.put(K,V5) tx.commit()
cache.lock(K)
が実行されると、K
でクラスターワイドのロックが取得されます。
cache.put(K,V5)
が実行されると、取得の成功が保証されます。
tx.commit()
が実行されると、この処理のために保持されたロックが開放されます。
9.5. 暗黙的な悲観的ロックの例
tx.begin() cache.put(K,V) cache.put(K2,V2) cache.put(K,V5) tx.commit()
- 行
cache.put(K,V)
が実行されると、K
でクラスターワイドのロックが取得されます。 - 行
cache.put(K2,V2)
が実行されると、K2
でクラスターワイドのロックが取得されます。 - 行
cache.put(K,V5)
が実行されると、K
のクラスターワイドのロックは以前取得されたため、ロックの取得は実行できませんが、put
操作は発生します。 - 行
tx.commit()
が実行されると、このトランザクションのために保持されたすべてのロックが開放されます。
9.6. 楽観的ロックと悲観的ロックの設定
transaction
要素内に locking
パラメーターを使用します。
次のように楽観的ロックを設定します。
<transaction locking="OPTIMISTIC" />
次のように悲観的ロックを設定します。
<transaction locking="PESSIMISTIC" />
9.7. ロック操作
9.7.1. LockManager について
LockManager
コンポーネントは、書き込み処理が始まる前にエントリーをロックします。LockManager
は LockContainer
を使用してロックを見つけたり、ロックを保持および作成します。このような実装では、通常 2 つのタイプの LockContainer
が使用されます。1 つ目のタイプはロックストライピングのサポート提供し、2 つ目のタイプはエントリーごとに 1 つのロックをサポートします。
関連トピック:
9.7.2. ロックの取得について
9.7.3. 平行性レベルについて
DataContainers
内部のコレクションなど、関連するすべての JDK ConcurrentHashMap
ベースのコレクションを調整します。
9.8. ロックストライピング
9.8.1. ロックストライピングについて
9.8.2. ロックストライピングの設定
striping
要素を true
に設定します。
<locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="true" />
9.8.3. ロックストライピングの代替
9.8.4. 共有ロックコレクションのサイズ設定
locking
設定要素の平行性レベル属性を使用して調整することができます。
9.9. 分離レベル
9.9.1. 分離レベルについて
READ_COMMITTED
と REPEATABLE_READ
の 2 つです。
READ_COMMITTED
は、幅広い要件に適用できるデフォルトの分離レベルです。REPEATABLE_READ
はlocking
設定要素を使用して設定できます。
9.9.2. READ_COMMITTED について
READ_COMMITTED
は JBoss Data Grid で使用できる 2 つの分離モードの 1 つです。
READ_COMMITTED
モードでは、書き込み操作はデータ自体ではなくデータのコピーとして作成されます。書き込み操作は他のデータの書き込みをブロックしますが、書き込みは読み出し操作をブロックしません。そのため、READ_COMMITTED
と REPEATABLE_READ
の両モードは、書き込み操作がいつ発生するかに関係なく、いつでも読み取り操作を許可します。
READ_COMMITTED
モードでは、読み取りの合間に書き込み操作によってデータが変更されると、トランザクション内で同じキーが複数読み取りされた場合に結果が異なる可能性があります。 これは、反復不可能読み出しと呼ばれ、REPEATABLE_READ
モードでは回避されます。
9.9.3. REPEATABLE_READ について
REPEATABLE_READ
は JBoss Data Grid で使用できる 2 つの分離モードの 1 つです。
REPEATABLE_READ
は読み取り操作中の書き込み操作や、書き込み操作時の読み取り操作を許可しません。これにより、単一のトランザクションの同じ行に 2 つの読み取り操作があるのに読み出した値が異なる時に発生する「反復不可能読み取り」が起こらないようにします。
REPEATABLE_READ
分離モードは、変更が発生する前に行の値を保存します。これにより、同じ行の 2番目の読み取り操作は変更された新しい値ではなく、保存された値を読み出すため、「反復不可能読み取り」の発生を防ぐことができます。そのため、読み出しの合間に書き込み操作が発生しても、2 つの読み取り操作によって読み出される 2 つの値は常に同じになります。
第10章 キャッシュストアとキャッシュローダー
10.1. キャッシュストアについて
- キャッシュにコピーがない時にデータストアよりデータを取り込みます。
- キャッシュのデータに加えられた変更をデータストアにプッシュします。
10.2. ファイルシステムベースのキャッシュストアについて
FileCacheStore
が含まれています。
FileCacheStore
はシンプルなファイルシステムベースの実装です。
FileCacheStore
には制限があるため、実稼働環境では制限内での使用が可能です。適切なファイルロックがなく、データが破損する原因となるため、共有ファイルシステム (NFS や Windows の共有など) 上では使用しないでください。また、ファイルシステムは本質的にトランザクションではないため、トランザクションコンテキストでキャッシュが使用されると、コミットフェーズ中にファイルが障害を書き込む原因となります。
FileCacheStore
はテストでの使用に適していますが、高度な平行性やトランザクション、ストレスベースの環境における使用には適していません。
10.3. ファイルキャッシュストアの設定
<local-cache name="default"> <file-store /> </local-cache>
- キャッシュの名前を指定するため、
local-cache
属性のname
パラメーターが使用されます。 file-store
要素はファイルキャッシュストアの設定情報を指定します。この要素の属性には、名前付きパスを定義するために使用されるrelative-to
パラメーターや、relative-to
内のディレクトリを指定するために使用されるpath
パラメーターが含まれます。
10.4. リモートキャッシュストア
10.4.1. リモートキャッシュストアについて
RemoteCacheStore
は、リモート JBoss Data Grid クラスターにデータを保存するキャッシュローダーの実装です。RemoteCacheStore
は Hot Rod クライアントサーバーアーキテクチャーを使用してリモートクラスターを通信します。
RemoteCacheStore
とクラスターとの間の接続を細かく調整する機能も提供します。
10.4.2. リモートキャッシュストアの設定 (リモートクライアントサーバーモード)
<remote-store cache="default" socket-timeout="60000" tcp-no-delay="true" fetch-state="false" passivation="true" preload="true" purge="false"> <remote-server outbound-socket-binding="remote-store-hotrod-server" /> </remote-store>
10.4.3. リモートキャッシュストアの設定 (ライブラリモード)
hotrod.properties
という名前のファイルを作成し、関連するクラスパスに含まれるようにします。
JBoss Data Grid のライブラリモードにおけるリモートキャッシュストアの設定例は次の通りです。
<loaders shared="true" preload="true" purge="false"> <loader class="org.infinispan.loaders.remote.RemoteCacheStore"> <properties> <property name="remoteCacheName" value="default"/> <property name="hotRodClientPropertiesFile" value="hotrod.properties" /> </properties> </loader> </loaders>
重要
hotRodClientPropertiesFile
と命名されたリモートキャッシュストアは、hotrod.properties
ファイルを参照します。適切に操作するには、このファイルをリモートキャッシュストアに対して定義する必要があります。
10.4.4. リモートキャッシュストア設定の属性
remote-store
要素は、Hot Rod を使用してアクセスされるリモートキャッシュストアの設定情報を指定します。remote-store
要素内に定義されるプロパティーは Hot Rod のクライアントプロパティーとして処理されます。
cache
パラメーターは使用されているキャッシュの名前を指定します。socket-timeout
パラメーターは、リモートキャッシュのソケットタイムアウトの時間を指定します。tcp-no-delay
パラメーターは、TCP パケットが遅延され一括して送信されるかを指定します。このパラメーターの有効な値はtrue
とfalse
になります。fetch-state
パラメーターは、クラスターへ参加する時に永続ステートが取り込まれるかを決定します。このパラメーターの有効な値はtrue
とfalse
になります。passivation
パラメーターは、キャッシュのエントリーがパッシベートされるか (true
) またはキャッシュストアが内容のコピーをメモリーに保持するか (false
) を決定します。preload
パラメーターは、起動中にエントリーをキャッシュにロードするかを指定します。このパラメーターの有効な値はtrue
とfalse
になります。purge
パラメーターは、キャッシュストアの起動時にキャッシュストアがパージされるかどうかを指定します。このパラメーターの有効な値はtrue
とfalse
になります。
remote-server
要素はリモートキャッシュストアによって使用されるリモートサーバーに関する情報を提供します。
outbound-socket-binding
パラメーターは、リモートキャッシュストアのアウトバウンドソケットを指定します。
重要
standalone.xml
ファイルにも定義します。
10.4.5. hotrod.properties ファイル
infinispan.client.hotrod.server_list=remote-server:11222
infinispan.client.hotrod.request_balancing_strategy
- レプリケートされた Hot Rod サーバークラスターでは、このストラテジーに従ってクライアントがサーバーへの要求のバランスを取ります。このプロパティーのデフォルト値は
org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy
です。 infinispan.client.hotrod.server_list
- 接続する Hot Rod サーバーの初期リストです。「host1:port1;host2:port2」 のような形式で指定されます。最低でも 1 つの host:port を指定する必要があります。このプロパティーのデフォルト値は
127.0.0.1:11222
です。 infinispan.client.hotrod.force_return_values
- すべての呼び出しに対して暗黙的に Flag.FORCE_RETURN_VALUE を行うかどうか。このプロパティーのデフォルト値は
false
です。 infinispan.client.hotrod.tcp_no_delay
- TCP スタックの TCP NODELAY に影響します。このプロパティーのデフォルト値は
true
です。 infinispan.client.hotrod.ping_on_startup
- true の場合、クラスターのトポロジーを取り込むため、ping リクエストがバックエンドサーバーへ送信されます。このプロパティーのデフォルト値は
true
です。 infinispan.client.hotrod.transport_factory
- 使用されるトランスポートを制御します。現在、TcpTransport のみがサポートされます。このプロパティーのデフォルト値は
org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory
です。 infinispan.client.hotrod.marshaller
- ユーザーオブジェクトをシリアライズおよびデシリアライズするため、カスタムマーシャラーの実装を指定できるようにします。このプロパティーのデフォルト値は
org.infinispan.marshall.jboss.GenericJBossMarshaller
です。 infinispan.client.hotrod.async_executor_factory
- 非同期呼び出しのカスタム非同期エクゼキューターを指定できるようにします。このプロパティーのデフォルト値は
org.infinispan.client.hotrod.impl.async.DefaultAsyncExecutorFactory
です。 infinispan.client.hotrod.default_executor_factory.pool_size
- デフォルトのエクゼキューターが使用される場合、エクゼキューターを初期化するスレッド数を設定します。このプロパティーのデフォルト値は
10
です。 infinispan.client.hotrod.default_executor_factory.queue_size
- デフォルトのエクゼキューターが使用される場合、エクゼキューターを初期化するキューサイズを設定します。このプロパティーのデフォルト値は
100000
です。 infinispan.client.hotrod.hash_function_impl.1
- ハッシュ関数のバージョンと使用中の一貫したハッシュアルゴリズムを指定します。使用される Hot Rod サーバーのバージョンと密接に関係しています。このプロパティーのデフォルト値は
Hash function specified by the server in the responses as indicated in ConsistentHashFactory
です。 infinispan.client.hotrod.key_size_estimate
- このヒントは、キーをシリアライズおよびデシリアライズする時にアレイのサイズ変更を最小限にするため、バイトバッファーのサイズを設定できるようにします。このプロパティーのデフォルト値は
64
です。 infinispan.client.hotrod.value_size_estimate
- このヒントは、値をシリアライズおよびデシリアライズする時にアレイのリサイズを最小限にするため、バイトバッファーをサイジングできるようにします。このプロパティーのデフォルト値は
512
です。 infinispan.client.hotrod.socket_timeout
- このプロパティーは、サーバーからのバイト待ちを断念する前の最大ソケット読み取りタイムアウトを定義します。The default value for this property is
60000 (equals 60 seconds)
. infinispan.client.hotrod.protocol_version
- このプロパティーは、クライアントが使用する必要があるプロトコルのバージョンを定義します。他の有効値には 1.0 が含まれます。このプロパティーのデフォルト値は
1.1
です。 infinispan.client.hotrod.connect_timeout
- このプロパティーは、サーバーへの接続を断念する前の最大ソケット接続タイムアウトを定義します。The default value for this property is
60000 (equals 60 seconds)
.
10.4.6. リモートキャッシュストアのアウトバウンドソケットの定義
standalone.xml
ファイルの outbound-socket-binding
要素を使用して定義されます。
standalone.xml
ファイルにおけるこの設定の例は次の通りです。
<outbound-socket-binding name="remote-store-hotrod-server"> <remote-destination host="127.0.0.1" port="11322"/> </outbound-socket-binding>
10.5. JDBC ベースのキャッシュストア
10.5.1. JDBC ベースのキャッシュストアについて
JdbcBinaryCacheStore
JdbcStringBasedCacheStore
JdbcMixedCacheStore
10.5.2. JDBC キャッシュの選択
JdbcStringBasedCacheStore
はストレス下でより優れたスループットを提供するため、キータイプを制御する場合に適しています。
JdbcStringBasedCacheStore
は、Key2StringMapper
を書いてキーを文字列オブジェクトにマップできる場合のみ使用することができます。JdbcStringBasedCacheStore
を使用できない場合、JdbcBinaryCacheStore
または JdbcMixedCacheStore
を代わりに使用できます。JdbcStringBasedCacheStore
がほとんどのキーを処理し、Key2StringMapper
を使用して一部のキーを変換できない場合に JdbcMixedCacheStore
を使用するのがよいでしょう。
10.5.3. JdbcBinaryCacheStores
10.5.3.1. JdbcBinaryCacheStore について
JdbcBinaryCacheStore
はすべてのキータイプをサポートします。同じテーブル行/Blob の同じハッシュ値 (キー上の hashCode
メソッド) を持つすべてのキーを格納します。含まれるキーに共通するハッシュ値が、テーブルの行/Blob の主キーとして設定されます。このハッシュ値により、JdbcBinaryCacheStore
は大変優れた柔軟性を提供しますが、平行性とスループットが犠牲になります。
k1
、k2
、k3
) のハッシュコードが同じである場合、同じテーブル行に格納されます。3 つの異なるスレッドが k1
、k2
、k3
を同時に更新しようとすると、すべてのキーが同じ行を共有するため同時には更新できないため、順次更新する必要があります。
10.5.3.2. パッシベーションを有効にした JdbcBinaryCacheStore リモート設定
JdbcBinaryCacheStore
の設定です。
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default"> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" start="EAGER"> <local-cache name="default" start="EAGER" batching="false" indexing="NONE"> <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false" /> <transaction mode="NONE" /> <eviction strategy="LRU" max-entries="2" /> <binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="true" preload="false" purge="false"> <property name="databaseType">${database.type}</property> <binary-keyed-table prefix="JDG"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </binary-keyed-table> </binary-keyed-jdbc-store> </local-cache> </cache-container> </subsystem>
10.5.3.3. パッシベーションを無効にした JdbcBinaryCacheStore リモート設定
JdbcBinaryCacheStore
の設定です。
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default"> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" start="EAGER"> <local-cache name="default" start="EAGER" batching="false" indexing="NONE"> <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false" /> <transaction mode="NONE" /> <binary-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="true" purge="false"> <property name="databaseType">${database.type}</property> <binary-keyed-table prefix="JDG"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </binary-keyed-table> </binary-keyed-jdbc-store> </local-cache> </cache-container> </subsystem>
10.5.3.4. JdbcBinaryCacheStore リモート設定の属性
JdbcBinaryCacheStore
を設定するために使用される要素とパラメーターの一覧は次の通りです。
cache-container
要素は、次のパラメーターを使用してキャッシュコンテナに関する情報を指定します。
name
パラメーターはキャッシュコンテナの名前を定義します。default-cache
パラメーターは、キャッシュコンテナと共に使用されるデフォルトキャッシュの名前を定義します。listener-executor
は非同期キャッシュリスナーの通知に使用されるエクゼキューターを定義します。start
パラメーターはキャッシュコンテナが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値はEAGER
とLAZY
です。
local-cache
要素は次のパラメーターを使用して、キャッシュコンテナと共に使用されるローカルキャッシュに関する情報を指定します。
name
パラメーターは使用するローカルキャッシュの名前を指定します。start
パラメーターはキャッシュが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値はEAGER
とLAZY
です。batching
パラメーターは、ローカルキャッシュに対してバッチ処理が有効であるかを指定します。indexing
パラメーターはローカルキャッシュに使用される索引作業のタイプを指定します。このパラメーターの有効な値はNONE
、LOCAL
、およびALL
です。
locking
要素はローカルキャッシュのロック設定を指定します。
isolation
パラメーターはローカルキャッシュに使用される分離レベルを定義します。このパラメーターに有効な値はREPEATABLE_READ
とREAD_COMMITTED
です。acquire-timeout
パラメーターは取得した操作がタイムアウトするミリ秒単位の値を指定します。concurrency-level
パラメーターは LockManager によって使用されるロックストライプの数を定義します。striping
パラメーターは、ロックストライピングがローカルキャッシュに使用されるかどうかを指定します。
transaction
要素はローカルキャッシュのトランザクション関連の設定を指定します。
mode
パラメーターはローカルキャッシュに使用されるトランザクションモードを指定します。このパラメーターの有効な値はNONE
、NON_XA
(XAResource を使用しない)、NON_DURABLE_XA
(リカバリーを用いずに XAResource を使用する) およびFULL_XA
(リカバリーを用いて XAResource を使用する) です。
eviction
要素はローカルキャッシュのエビクション設定情報を指定します。
strategy
パラメーターは使用されるエビクションストラテジーやアルゴリズムを指定します。このパラメーターの有効な値にはNONE
、FIFO
、LRU
、UNORDERED
、LIRS
などがあります。max-entries
パラメーターはキャッシュインスタンスにおけるエントリーの最大数を指定します。
binary-keyed-jdbc-store
要素は、バイナリのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
datasource
パラメーターはデータソースの JNDI 名を定義します。passivation
パラメーターは、キャッシュのエントリーがパッシベートされるか (true
) またはキャッシュストアが内容のコピーをメモリーに保持するか (false
) を決定します。preload
パラメーターは、起動中にエントリーをキャッシュにロードするかを指定します。このパラメーターの有効な値はtrue
とfalse
になります。purge
パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターで有効な値はtrue
とfalse
です。
property
要素には、キャッシュストアに関連するプロパティーに関する情報が含まれます。
name
パラメーターはキャッシュストアの名前を指定します。- ${database.type} を有効なデータベースタイプの値 (
DB2_390
、SQL_SERVER
、MYSQL
、ORACLE
、POSTGRES
、SYBASE
など) に置き換える必要があります。
binary-keyed-table
要素は、バイナリのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
prefix
パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
id-column
要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
data-column
要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
timestamp-column
要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
10.5.3.5. JdbcBinaryCacheStore のライブラリーモード設定
JdbcBinaryCacheStore
の設定例は次の通りです。
<loaders> <loader class="org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore" fetchPersistentState="false"ignoreModifications="false" purgeOnStartup="false"> <properties> <property name="bucketTableNamePrefix" value="ISPN_BUCKET_TABLE"/> <property name="idColumnName" value="ID_COLUMN"/> <property name="dataColumnName" value="DATA_COLUMN"/> <property name="timestampColumnName" value="TIMESTAMP_COLUMN"/> <property name="timestampColumnType" value="BIGINT"/> <property name="connectionFactoryClass" value="org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory"/> <property name="connectionUrl" value="jdbc:h2:mem:infinispan_binary_based;DB_CLOSE_DELAY=-1"/> <property name="userName" value="sa"/> <property name="driverClass" value="org.h2.Driver"/> <property name="idColumnType" value="VARCHAR(255)"/> <property name="dataColumnType" value="BINARY"/> <property name="dropTableOnExit" value="true"/> <property name="createTableOnStart" value="true"/> </properties> </loader> </loaders>
10.5.4. JdbcStringBasedCacheStores
10.5.4.1. JdbcStringBasedCacheStore について
JdbcStringBasedCacheStore
は複数のエントリーを各行にグループ化せずに、各エントリーをテーブルの独自の行に格納するため、平行負荷下でスループットが増加します。また、各キーを String
オブジェクトへマッピングする (プラグ可能な) 全単射も使用します。Key2StringMapper
インターフェースは全単射を定義します。
DefaultTwoWayKey2StringMapper
と呼ばれるデフォルトの実装が含まれています。
10.5.4.2. 複数ノードの JdbcStringBasedCacheStore リモート設定
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default"> <cache-container name="default" default-cache="memcachedCache" listener-executor="infinispan-listener" start="EAGER"> <transport stack="${stack}" executor="infinispan-transport" lock-timeout="240000"/> <replicated-cache name="memcachedCache" start="EAGER" mode="SYNC" batching="false" indexing="NONE" remote-timeout="60000"> <locking isolation="REPEATABLE_READ" acquire-timeout="30000" concurrency-level="1000" striping="false" /> <transaction mode="NONE" /> <state-transfer enabled="true" timeout="60000" /> <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" fetch-state="true" passivation="false" preload="false" purge="false" shared="false" singleton="true"> <property name="databaseType">${database.type}</property> <string-keyed-table prefix="JDG"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </string-keyed-table> </string-keyed-jdbc-store> </replicated-cache> </cache-container> </subsystem>
10.5.4.3. パッシベーションを有効にした JdbcStringBasedCacheStore リモート設定
JdbcBinaryCacheStore
の例になります。
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default"> <cache-container name="default" default-cache="memcachedCache" listener-executor="infinispan-listener" start="EAGER"> <local-cache name="memcachedCache" start="EAGER" batching="false" indexing="NONE"> <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false" /> <transaction mode="NONE" /> <eviction strategy="LRU" max-entries="2" /> <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="true" preload="false" purge="false"> <property name="databaseType">${database.type}</property> <string-keyed-table prefix="JDG"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </string-keyed-table> </string-keyed-jdbc-store> </local-cache> </cache-container> </subsystem>
10.5.4.4. パッシベーションを無効にした JdbcStringBasedCacheStore リモート設定
JdbcStringBasedCacheStore
の設定になります。
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default"> <cache-container name="default" default-cache="memcachedCache" listener-executor="infinispan-listener" start="EAGER"> <local-cache name="memcachedCache" start="EAGER" batching="false" indexing="NONE"> <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false" /> <transaction mode="NONE" /> <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="true" purge="false"> <property name="databaseType">${database.type}</property> <string-keyed-table prefix="JDG"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </string-keyed-table> </string-keyed-jdbc-store> </local-cache> </cache-container> </subsystem>
10.5.4.5. JdbcStringBasedCacheStore リモート設定の属性
JdbcStringBasedCacheStore
を設定するために使用される属性とパラメーターの一覧は次の通りです。
cache-container
要素はキャッシュコンテナに関する情報を指定します。
name
パラメーターはキャッシュコンテナの名前を定義します。default-cache
パラメーターは、キャッシュコンテナと共に使用されるデフォルトキャッシュの名前を定義します。listener-executor
は非同期キャッシュリスナーの通知に使用されるエクゼキューターを定義します。start
パラメーターはキャッシュコンテナが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値はEAGER
とLAZY
です。
local-cache
要素はキャッシュコンテナと共に使用されるローカルキャッシュに関する情報を指定します。
name
パラメーターは使用するローカルキャッシュの名前を指定します。start
パラメーターはキャッシュが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値はEAGER
とLAZY
です。batching
パラメーターは、ローカルキャッシュに対してバッチ処理が有効であるかを指定します。indexing
パラメーターはローカルキャッシュに使用される索引作業のタイプを指定します。このパラメーターの有効な値はNONE
、LOCAL
、およびALL
です。
transport
要素には、キャッシュコンテナによって使用されるトランスポートの説明が含まれます。
stack
パラメーターはトランスポートに使用される JGroups スタックを指定します。executor
パラメーターはトランスポートに使用されるエクゼキューターを指定します。lock-timeout
パラメーターはトランスポートのロックに対するタイムアウト値を指定します。
replicated-cache
要素は使用中のレプリケートされたキャッシュに関する情報を指定します。
name
パラメーターはレプリケートされたキャッシュの名前を指定します。start
パラメーターはキャッシュが要求時または即座に起動するかどうかを指定します。このパラメーターの有効な値はEAGER
とLAZY
です。mode
パラメーターはレプリケートされたキャッシュのキャッシュモードを指定します。このパラメーターの有効な値はSYNC
とASYNC
です。batching
パラメーターは、レプリケートされたキャッシュにバッチ処理を使用できるかどうかを指定します。indexing
パラメーターは、キャッシュに追加されたエントリーが索引付けされるかどうかを指定します。有効な場合、レプリケートされたキャッシュのエントリーが変更または削除された時に索引が更新されます。remote-timeout
パラメーターは、リモート呼び出しが受信確認を待機する期間を指定します。指定期間の後、リモート呼び出しは待機を中止し、例外がスローされます。このパラメーターはASYNC
モードパラメーターと共に使用されます。
locking
要素はローカルキャッシュのロック設定を指定します。
isolation
パラメーターはローカルキャッシュに使用される分離レベルを定義します。このパラメーターに有効な値はREPEATABLE_READ
とREAD_COMMITTED
です。acquire-timeout
パラメーターは取得した操作がタイムアウトするミリ秒単位の値を指定します。concurrency-level
パラメーターは LockManager によって使用されるロックストライプの数を定義します。striping
パラメーターは、ロックストライピングがローカルキャッシュに使用されるかどうかを指定します。
transaction
要素はローカルキャッシュのトランザクション関連の設定を指定します。
mode
パラメーターはローカルキャッシュに使用されるトランザクションモードを指定します。このパラメーターの有効な値はNONE
、NON_XA
(XAResource を使用しない)、NON_DURABLE_XA
(リカバリーを用いずに XAResource を使用する) およびFULL_XA
(リカバリーを用いて XAResource を使用する) です。
eviction
要素はローカルキャッシュのエビクション設定情報を指定します。
strategy
パラメーターは使用されるエビクションストラテジーやアルゴリズムを指定します。このパラメーターの有効な値にはNONE
、FIFO
、LRU
、UNORDERED
、LIRS
などがあります。max-entries
パラメーターはキャッシュインスタンスにおけるエントリーの最大数を指定します。
string-keyed-jdbc-store
要素は、文字列ベースのキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
datasource
パラメーターはデータソースの JNDI 名を定義します。passivation
パラメーターは、キャッシュのエントリーがパッシベートされるか (true
) またはキャッシュストアが内容のコピーをメモリーに保持するか (false
) を決定します。preload
パラメーターは、起動中にエントリーをキャッシュにロードするかどうかを指定します。このパラメーターで有効な値はtrue
とfalse
です。purge
パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターで有効な値はtrue
とfalse
です。shared
パラメーターは、複数のキャッシュストアインスタンスがキャッシュストアを共有する場合に使用されます。複数のキャッシュインスタンスが同じ変更内容を複数回書き込まないようにするため、このパラメーターを設定することができます。このパラメーターに有効な値はENABLED
とDISABLED
です。singleton
パラメーターは、クラスターが基盤のストアと対話する場合に使用されるシングルトンストアを有効にします。
property
要素には、キャッシュストアに関連するプロパティーに関する情報が含まれます。
name
パラメーターはキャッシュストアの名前を指定します。- ${database.type} を有効なデータベースタイプの値 (
DB2_390
、SQL_SERVER
、MYSQL
、ORACLE
、POSTGRES
、SYBASE
など) に置き換える必要があります。
string-keyed-table
要素は、文字別ベースのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
prefix
パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
id-column
要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
data-column
要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
timestamp-column
要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
10.5.4.6. JdbcStringBasedCacheStore のライブラリーモード設定
JdbcStringBasedCacheStore
の設定例は次の通りです。
<loaders> <loader class="org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore" fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false"> <properties> <property name="stringsTableNamePrefix" value="ISPN_STRING_TABLE"/> <property name="idColumnName" value="ID_COLUMN"/> <property name="dataColumnName" value="DATA_COLUMN"/> <property name="timestampColumnName" value="TIMESTAMP_COLUMN"/> <property name="timestampColumnType" value="BIGINT"/> <property name="connectionFactoryClass" value="org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory"/> <property name="connectionUrl" value="jdbc:h2:mem:string_based_db;DB_CLOSE_DELAY=-1"/> <property name="userName" value="sa"/> <property name="driverClass" value="org.h2.Driver"/> <property name="idColumnType" value="VARCHAR(255)"/> <property name="dataColumnType" value="BINARY"/> <property name="dropTableOnExit" value="true"/> <property name="createTableOnStart" value="true"/> </properties> </loader> </loaders>
10.5.5. JdbcMixedCacheStore
10.5.5.1. JdbcMixedCacheStore について
JdbcMixedCacheStore
は、キーのタイプを基にキーを JdbcBinaryCacheStore
または JdbcStringBasedCacheStore
に委譲するハイブリッド実装です。
10.5.5.2. パッシベーションを有効にした JdbcMixedCacheStore リモート設定
JdbcMixedCacheStore
の設定になります。
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default"> <cache-container name="default" default-cache="memcachedCache" listener-executor="infinispan-listener" start="EAGER"> <local-cache name="memcachedCache" start="EAGER" batching="false" indexing="NONE"> <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false" /> <transaction mode="NONE" /> <eviction strategy="LRU" max-entries="2" /> <mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="true" preload="false" purge="false"> <property name="databaseType">${database.type}</property> <binary-keyed-table prefix="MIX_BKT2"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </binary-keyed-table> <string-keyed-table prefix="MIX_STR2"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </string-keyed-table> </mixed-keyed-jdbc-store> </local-cache> </cache-container> </subsystem>
10.5.5.3. パッシベーションを無効にした JdbcMixedCacheStore リモート設定
JdbcMixedCacheStore
の設定になります。
<subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="default"> <cache-container name="default" default-cache="memcachedCache" listener-executor="infinispan-listener" start="EAGER"> <local-cache name="memcachedCache" start="EAGER" batching="false" indexing="NONE"> <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false" /> <transaction mode="NONE" /> <mixed-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="true" purge="false"> <property name="databaseType">${database.type}</property> <binary-keyed-table prefix="MIX_BKT"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </binary-keyed-table> <string-keyed-table prefix="MIX_STR"> <id-column name="id" type="${id.column.type}"/> <data-column name="datum" type="${data.column.type}"/> <timestamp-column name="version" type="${timestamp.column.type}"/> </string-keyed-table> </mixed-keyed-jdbc-store> </local-cache> </cache-container> </subsystem>
10.5.5.4. JdbcMixedCacheStore リモート設定の属性
JdbcMixedCacheStore
を設定するために使用される要素とパラメーターの一覧は次の通りです。
cache-container
要素は、次のパラメーターを使用してキャッシュコンテナに関する情報を指定します。
name
パラメーターはキャッシュコンテナの名前を定義します。default-cache
パラメーターは、キャッシュコンテナと共に使用されるデフォルトキャッシュの名前を定義します。listener-executor
は非同期キャッシュリスナーの通知に使用されるエクゼキューターを定義します。start
パラメーターはキャッシュコンテナが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値はEAGER
とLAZY
です。
local-cache
要素は次のパラメーターを使用して、キャッシュコンテナと共に使用されるローカルキャッシュに関する情報を指定します。
name
パラメーターは使用するローカルキャッシュの名前を指定します。start
パラメーターはキャッシュが起動する場所を示します (要求時またはサーバー起動時にレイジーに起動するかなど)。このパラメーターの有効な値はEAGER
とLAZY
です。batching
パラメーターは、ローカルキャッシュに対してバッチ処理が有効であるかを指定します。indexing
パラメーターはローカルキャッシュに使用される索引作業のタイプを指定します。このパラメーターの有効な値はNONE
、LOCAL
、およびALL
です。
locking
要素はローカルキャッシュのロック設定を指定します。
isolation
パラメーターはローカルキャッシュに使用される分離レベルを定義します。このパラメーターに有効な値はREPEATABLE_READ
とREAD_COMMITTED
です。acquire-timeout
パラメーターは取得した操作がタイムアウトするミリ秒単位の値を指定します。concurrency-level
パラメーターは LockManager によって使用されるロックストライプの数を定義します。striping
パラメーターは、ロックストライピングがローカルキャッシュに使用されるかどうかを指定します。
transaction
要素はローカルキャッシュのトランザクション関連の設定を指定します。
mode
パラメーターはローカルキャッシュに使用されるトランザクションモードを指定します。このパラメーターの有効な値はNONE
、NON_XA
(XAResource を使用しない)、NON_DURABLE_XA
(リカバリーを用いずに XAResource を使用する) およびFULL_XA
(リカバリーを用いて XAResource を使用する) です。
eviction
要素はローカルキャッシュのエビクション設定情報を指定します。
strategy
パラメーターは使用されるエビクションストラテジーやアルゴリズムを指定します。このパラメーターの有効な値にはNONE
、FIFO
、LRU
、UNORDERED
、LIRS
などがあります。max-entries
パラメーターはキャッシュインスタンスにおけるエントリーの最大数を指定します。
mixed-keyed-jdbc-store
要素は、混合のキーボードから情報が入力されたキャッシュの JDBC ストアに対する設定を指定します。
datasource
パラメーターはデータソースの JNDI 名を定義します。passivation
パラメーターは、キャッシュのエントリーがパッシベートされるか (true
) またはキャッシュストアが内容のコピーをメモリーに保持するか (false
) を決定します。preload
パラメーターは、起動中にエントリーをキャッシュにロードするかどうかを指定します。このパラメーターで有効な値はtrue
とfalse
です。purge
パラメーターは、起動時にキャッスストアがパージされるかどうかを指定します。 このパラメーターで有効な値はtrue
とfalse
です。
property
要素には、キャッシュストアに関連するプロパティーに関する情報が含まれます。
name
パラメーターはキャッシュストアの名前を指定します。- ${database.type} を有効なデータベースタイプの値 (
DB2_390
、SQL_SERVER
、MYSQL
、ORACLE
、POSTGRES
、SYBASE
など) に置き換える必要があります。
mixed-keyed-table
要素は、混合のキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
prefix
パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
string-keyed-table
要素は、文字別ベースのキャッシュエントリーを格納するために使用されるデータベーステーブルに関する情報を指定します。
prefix
パラメーターはデータベーステーブル名のプレフィックスの文字列を指定します。
id-column
要素は、キャッシュエントリーの ID を保持するデータベース列に関する情報を指定します。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
data-column
要素には、キャッシュエントリーデータを保持するデータベース列に関する情報が含まれます。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
timestamp-column
要素は、キャッシュエントリーのタイムスタンプを保持するデータベース列に関する情報を指定します。
name
パラメーターはデータベース列の名前を指定します。type
パラメーターはデータベース列のタイプを指定します。
10.5.5.5. JdbcMixedCacheStore のライブラリーモード設定
JdbcMixedCacheStore
の設定例は次の通りです。
<loaders> <loader class="org.infinispan.loaders.jdbc.mixed.JdbcMixedCacheStore" fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false"> <properties> <property name="tableNamePrefixForStrings" value="ISPN_MIXED_STR_TABLE"/> <property name="tableNamePrefixForBinary" value="ISPN_MIXED_BINARY_TABLE"/> <property name="idColumnNameForStrings" value="ID_COLUMN"/> <property name="idColumnNameForBinary" value="ID_COLUMN"/> <property name="dataColumnNameForStrings" value="DATA_COLUMN"/> <property name="dataColumnNameForBinary" value="DATA_COLUMN"/> <property name="timestampColumnNameForStrings" value="TIMESTAMP_COLUMN"/> <property name="timestampColumnNameForBinary" value="TIMESTAMP_COLUMN"/> <property name="timestampColumnTypeForStrings" value="BIGINT"/> <property name="timestampColumnTypeForBinary" value="BIGINT"/> <property name="connectionFactoryClass" value="org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory"/> <property name="connectionUrl" value="jdbc:h2:mem:infinispan_mixed_cs;DB_CLOSE_DELAY=-1"/> <property name="userName" value="sa"/> <property name="driverClass" value="org.h2.Driver"/> <property name="idColumnTypeForStrings" value="VARCHAR(255)"/> <property name="idColumnTypeForBinary" value="VARCHAR(255)"/> <property name="dataColumnTypeForStrings" value="BINARY"/> <property name="dataColumnTypeForBinary" value="BINARY"/> <property name="dropTableOnExitForStrings" value="false"/> <property name="dropTableOnExitForBinary" value="false"/> <property name="createTableOnStartForStrings" value="true"/> <property name="createTableOnStartForBinary" value="true"/> <property name="createTableOnStartForStrings" value="true"/> <property name="createTableOnStartForBinary" value="true"/> </properties> </loader> </loaders>
10.5.6. カスタムキャッシュストア
10.5.6.2. カスタムキャッシュストアの設定 (リモートモード)
<local-cache name="default"> <store class="my.package.CustomCacheStore"> <properties> <property name="customStoreProperty" value="10" /> </properties> </store> </local-cache>
重要
org.jboss.as.clustering.infinispan
モジュールの依存関係に追加します。
10.5.6.3. カスタムキャッシュストアの設定 (ライブラリモード)
<loaders shared="true" preload="true" purge="false"> <loader class="org.infinispan..custom.CustomCacheStore"> <properties> <property name="CustomCacheName" value="default"/> </properties> </loader> </loaders>
10.6. よくある質問
10.6.1. 非同期キャッシュストアの変更について
10.7. キャッシュストアのトラブルシューティング
10.7.1. JdbcStringBasedCacheStore の IOExceptions
JdbcStringBasedCacheStore
を使用している時に IOException Unsupported protocol version 48 エラーが発生した場合、データ列タイプが正しいタイプである BLOB
や VARBINARY
ではなく、VARCHAR
や CLOB
などに設定されていることを示しています。JdbcStringBasedCacheStore
は文字列であるキーのみを必要とし、値はバイナリ列に保存されるため、すべてのデータタイプを値に使用できます。
10.8. キャッシュローダー
10.8.1. キャッシュローダーについて
10.8.2. キャッシュローダーとキャッシュストア
CacheLoader
インターフェースと複数の実装が含まれていました。JBoss Data Grid ではこれらが CacheLoader
と CacheStore
の 2 つの異なるインターフェースに分割されました。CacheLoader
は以前に存在したステートを別の場所よりロードし、CacheStore
(CacheLoader
を拡張します) はメソッドを公開してステートを格納し、ロードします。この分割により、読み取り専用ソースの定義が容易になりました。
10.8.3. 共有キャッシュローダー
10.8.3.1. 共有キャッシュローダーについて
10.8.3.2. 共有キャッシュローダーの有効化
JBoss Data Grid のライブラリモードでは、loader
要素内で shared
パラメーターを使用してキャッシュローダーの共有を切り替えます。このパラメーターはデフォルトでは FALSE
に設定されています。キャッシュローダーの共有を有効にするには、shared
パラメーターを TRUE
に設定します。
JBoss Data Grid のリモートクライアントサーバーモードでは、store
要素内で shared
パラメーターを使用してキャッシュローダーの共有を切り替えます。このパラメーターはデフォルトでは FALSE
に設定されています。キャッシュローダーの共有を有効にするには、shared
パラメーターを TRUE
に設定します。例は次の通りです。
<jdbc-store shared="true"> ... </jdbc-store>
10.8.3.3. インバリデーションモードと共有キャッシュローダー
- 更新されたデータが含まれるレプリケーションメッセージよりも無効化メッセージはかなり小型であるため、ネットワークトラフィックが軽減されます。
- 残りのクラスターキャッシュは、必要な場合のみ変更されたデータを共有キャッシュローダーよりレイジーにルックアップするため、ネットワークトラフィックがさらに軽減されます。
10.8.3.4. キャッシュローダーとキャッシュパッシベーション
10.8.3.5. アプリケーションキャッシュローダーの登録
10.8.4. 接続ファクトリー
10.8.4.1. 接続ファクトリーについて
ConnectionFactory
実装に依存してデータベースへの接続を取得します。このプロセスは接続管理またはプーリングとも呼ばれます。
ConnectionFactoryClass
設定属性を使用して指定することができます。 JBoss Data Grid には次の ConnectionFactory
実装が含まれています。
- ManagedConnectionFactory
- SimpleConnectionFactory
10.8.4.2. ManagedConnectionFactory について
ManagedConnectionFactory
は、アプリケーションサーバーなど管理された環境内での使用に適した接続ファクトリーです。この接続ファクトリーは JNDI ツリー内の設定された場所を調査でき、接続管理を DataSource
へ委譲できます。 ManagedConnectionFactory
は DataSource
が含まれる管理された環境内で使用されます。この Datasource
は接続プーリングへ委譲されます。
10.8.4.3. SimpleConnectionFactory について
SimpleConnectionFactory
は呼び出しごとにデータベース接続を作成する接続ファクトリーです。この接続ファクトリーは実稼働環境での使用には向いていません。
第11章 キャッシュマネージャー
11.1. キャッシュマネージャーについて
11.2. 複数のキャッシュマネージャー
11.2.1. 単一のキャッシュマネージャーを用いた複数キャッシュの作成
11.2.2. 複数のキャッシュマネージャーの使用
第12章 エビクション
12.1. エビクションについて
12.2. エビクション操作
12.3. エビクションの用途
関連トピック:
12.4. エビクションストラテジー
12.4.1. エビクションストラテジーについて
EvictionStrategy.NONE
: 設定されているエビクションストラテジーはありません。EvictionStrategy.FIFO
: 先入れ先出しのエビクションストラテジーです。EvictionStrategy.LRU
: LRU (Least Recently Used) 方式のエビクションストラテジーです。幅広いデプロイメントの要件と互換性があるため、デフォルトのエビクションアルゴリズムとなっています。EvictionStrategy.UNORDERED
: 順番付けのないエビクションストラテジーです。EvictionStrategy.LIRS
: LIRS (Low Inter-reference Recency Set) 方式のエビクションストラテジーです。
12.4.2. LRU エビクションアルゴリズムの制限
- 1 度だけ使用できるアクセスエントリーを時間内に置き換えられない。
- 最初にアクセスされたエントリーが不必要に置き換えられる。
12.5. エビクションの使用
12.5.1. エビクションの初期化
max-entries
属性の値をゼロよりも大きい数に設定します。max-entries
の値セットを調整して、使用する設定の最適値を探します。max-entries
に設定する値が大きすぎると、JBoss Data Grid のメモリーが不足するため注意してください。
12.5.2. デフォルトのエビクション設定
eviction
要素を使用してエビクションを有効にすると、次のデフォルト値が使用されます。
- ストラテジー: 指定されたエビクションストラテジーがない場合、
EvictionStrategy.NONE
がデフォルトとみなされます。 - max-entries: 指定された値がない場合、
max-entries
の値は無制限のエントリーを許可する-1
に設定されます。max-entries
の値を0
に設定するとすべてのエントリーが拒否されます。そのため、エビクションスレッドは空のキャッシュを保持しようとします。
12.5.3. エビクションの設定例
JBoss Data Grid のライブラリーモードに有効なエビクションの XML 設定例は次の通りです。
<eviction strategy="LRU" maxEntries="2000"/>
以下を使用すると、JBoss Data Grid のライブラリモードでエビクションの設定をプログラムを用いて定義することが可能です。
Configuration c = new ConfigurationBuilder().eviction().strategy(EvictionStrategy.LRU) .maxEntries(2000) .build();
JBoss Data Grid のリモートクライアントサーバーモードで XML を用いたエビクションの設定例は次の通りです。
<eviction strategy="FIFO" max-entries="20"/>
注記
maxEntries
パラメーター、リモートクライアントサーバーモードは max-entries
パラメーターを使用することに注意してください。
12.5.4. エビクション設定のトラブルシューティング
configuration
要素の max-entries
パラメーターに指定された値よりも大きくすることができます。これは、max-entries
の値を 2 の累乗以外の値に設定することは可能ですが、基盤のアルゴリズムがこの値を V
(max-entries
の値に最も近い 2 を累乗した値) に変更するからです。エビクションアルゴリズムは、キャッシュコンテナのサイズが V
の値を越えないようにします。
12.6. エビクションとパッシベーション
12.6.1. エビクションとパッシベーションについて
関連トピック:
第13章 エクスパレーション
13.1. エクスパレーションについて
- ライフスパンの値。
- 最大アイドル時間の値。
-1
が作成時に割り当てられます。
13.2. エクスパレーションの操作
lifespan
) または最大アイドル時間 (ライブラリモードでは maxIdle
、リモートクライアントサーバーモードでは max-idle
) は、エントリーのキャッシュ全体のデフォルトよりも優先されます。
13.3. エビクションとエクスパレーションの比較
lifespan
) とアイドル時間 (ライブラリモードでは maxIdle
、リモートクライアントサーバーモードでは max-idle
) の値は、各キャッシュエントリーと一緒にレプリケートされます。
13.4. キャッシュエントリーの期限切れ通知
- ユーザースレッドがエントリーを要求し、そのエントリーが期限切れであることが判明した場合。
- エントリーがディスクへパッシベートまたはオーバフローされ、期限切れであることが判明した場合。
- エビクションメンテナンススレッドが見つけたエントリーが期限切れであることが判明した場合。
13.5. エクスパレーションの設定
次の設定例は、JBoss Data Grid のライブラリモードでエクスパレーションを設定する方法を示しています。
<expiration lifespan="2000" maxIdle="1000" />
次の設定例は、JBoss Data Grid のリモートクライアントサーバーモードでエクスパレーションを設定する方法を示しています。
<expiration lifespan="2000" max-idle="1000" />
13.6. 期限つき (mortal) データと期限なし (immortal) データ
13.6.1. データ期限について
put(key, value)
を使用すると、期限なし (immortal) エントリーと呼ばれる永久に期限切れにならないエントリーが作成されます。また、put(key, value, lifespan, timeunit)
を使用して作成されるエントリーは、指定の固定ライフスパンを持つ期限つき (mortal) エントリーで、ライフスパンの後に期限が切れます。
lifespan
パラメーターの他に、エクスパレーションを判断するために使用される maxIdle
パラメーターも提供します。maxIdle
パラメーターと lifespan
パラメーターをさまざまな組み合わせで使用してエントリーのライフスパンを設定することができます。
13.6.2. デフォルトのデータ期限
13.6.3. データ期限の設定
13.7. トラブルシューティング
13.7.1. エクスパレーションのトラブルシューティング
put()
のような複数キャッシュの操作は、ライフスパン値をパラメーターとして渡されます。この値は間隔を定義し、この間隔の後にエントリーが期限切れになります。エビクションが設定されていない状態でライフスパンの間隔が期限切れになると、JBoss Data Grid がエントリーを削除しなかったように見受けられます。例えば、number of entries など JMX の統計を表示する場合、無効の数字が表示されたり、JBoss Data Grid に関連する永続ストアにこのエントリーが依然含まれていることがあります。JBoss Data Grid は背後でこのエントリーを期限切れエントリーとしてマーク付けしても、削除しません。このようなエントリーの削除は、以下の場合の 1 つに該当すると実行されます。
- 期限切れエントリーに対して
get()
またはcontainsKey()
の使用を試みると、JBoss Data Grid がエントリーを期限切れとして検出し、削除します。 - エビクション機能を有効にすると、エビクションスレッドが周期的に期限切れエントリーを検出し、パージします。
第14章 1 次キャッシュ
14.1. 1 次キャッシュについて
disabled
になっています。
14.2. 1 次キャッシュエントリー
14.2.1. 1 次キャッシュエントリー
14.2.2. 1 次キャッシュエントリーのライフスパン
600,000
ミリ秒 (10 分) です。このライフスパン値はユーザーの要件に合わせて変更することが可能です。
14.3. 1 次キャッシュの操作
14.3.1. 1 次キャッシュと無効化
14.3.2. GET 操作と用いた 1 次キャッシュの使用
GET
操作が実行されると、リモート呼び出しが繰り返し生成されます。同じキー上で不必要な GET
操作の数を削減するには、L1 キャッシングを有効にします。
第15章 リスナーと通知
15.1. リスナー API について
15.2. リスナーの例
@Listener public class PrintWhenAdded { @CacheEntryCreated public void print(CacheEntryCreatedEvent event) { System.out.println("New entry " + event.getKey() + " created in the cache"); } }
15.3. キャッシュエントリーが変更されたリスナーの設定
isPre
が false
である場合に、変更された値を Cache.get()
より読み出しできません。
CacheEntryModifiedEvent.getValue()
を使用して、変更されたエントリーの新しい値を読み出します。
15.4. 通知
15.4.1. リスナー通知について
@Listener
アノテーションが付きます。Listenable は、実装がアタッチするリスナーを持つことを意味するインターフェースです。各リスナーは Listenable で定義されたメソッドを使用して登録されます。
15.4.2. キャッシュレベルの通知について
関連トピック:
15.4.3. キャッシュマネージャーレベルの通知
- クラスターに参加または離脱するノード
- キャッシュの開始および停止
15.4.4. 同期および非同期通知について
@Listener (sync = false)public class MyAsyncListener { .... }
<asyncListenerExecutor/>
要素を使用して、非同期通知を送信するために使用されるスレッドプールを調整します。
15.5. Futures の通知
15.5.1. NotifyingFutures について
Futures
を返しませんが、NotifyingFuture
と呼ばれるサブインターフェースを返します。JDK の Future
とは異なり、終了した future についてユーザーに通知するため、リスナーを NotifyingFuture
にアタッチすることが可能です。
注記
NotifyingFutures
はライブラリモードでのみ使用可能です。
15.5.2. NotifyingFutures の例
NotifyingFutures
を使用する方法を示しています。
FutureListener futureListener = new FutureListener() { public void futureDone(Future future) { try { future.get(); } catch (Exception e) { // Future did not complete successfully System.out.println("Help!"); } } }; cache.putAsync("key", "value").attachListener(futureListener);
第16章 アクティベーションモードとパッシベーションモード
16.1. アクティベーションモードについて
16.2. パッシベーションモードについて
16.3. パッシベーションモードの利点
16.4. パッシベーションフラグについて
16.5. エビクションとパッシベーション
16.5.1. エビクションとパッシベーションについて
16.5.2. エビクションとパッシベーションの用途
- パッシベートされたエントリーに関する通知がキャッシュリスナーへ送信されます。
- エビクトされたエントリーが保存されます。
16.5.3. パッシベーションが無効な場合のエビクションの例
表16.1 パッシベーションが無効な場合のエビクション
手順 | メモリー内のキー | ディスク上のキー |
---|---|---|
keyOne の挿入 | メモリー: keyOne | ディスク: keyOne |
keyTwo の挿入 | メモリー: keyOne 、 keyTwo | ディスク: keyOne 、 keyTwo |
エビクションスレッドが実行され、keyOne をエビクトする | メモリー: keyTwo | ディスク: keyOne 、 keyTwo |
keyOne の読み取り | メモリー: keyOne 、 keyTwo | ディスク: keyOne 、 keyTwo |
エビクションスレッドが実行され、keyTwo をエビクトする | メモリー: keyOne | ディスク: keyOne 、 keyTwo |
keyTwo の削除 | メモリー: keyOne | ディスク: keyOne |
16.5.4. パッシベーションが有効な場合のエビクションの例
表16.2 パッシベーションが有効な場合のエビクション
手順 | メモリー内のキー | ディスク上のキー |
---|---|---|
keyOne の挿入 | メモリー: keyOne | ディスク: |
keyTwo の挿入 | メモリー: keyOne 、 keyTwo | ディスク: |
エビクションスレッドが実行され、keyOne をエビクトする | メモリー: keyTwo | ディスク: keyOne |
keyOne の読み取り | メモリー: keyOne 、 keyTwo | ディスク: |
エビクションスレッドが実行され、keyTwo をエビクトする | メモリー: keyOne | ディスク: keyTwo |
keyTwo の削除 | メモリー: keyOne | ディスク: |
第17章 カスタムインターセプター
17.1. カスタムインターセプターについて
17.2. カスタムインターセプター設計
- カスタムインターセプターは
CommandInterceptor
を拡張しなければなりません。 - カスタムインターセプターはインスタンス化を可能にするために、パブリックの空のコンストラクターを宣言しなければなりません。
- カスタムインターセプターでは、
property
要素を介して定義されたプロパティーに対して JavaBean スタイルセッターを定義する必要があります。
17.3. カスタムインターセプターの追加
17.3.1. カスタムインターセプターを宣言して追加
<namedCache name="cacheWithCustomInterceptors"> <!-- Define custom interceptors. All custom interceptors need to extend org.jboss.cache.interceptors.base.CommandInterceptor --> <customInterceptors> <interceptor position="FIRST" class="com.mycompany.CustomInterceptor1"> <properties> <property name="attributeOne" value="value1" /> <property name="attributeTwo" value="value2" /> </properties> </interceptor> <interceptor position="LAST" class="com.mycompany.CustomInterceptor2"/> <interceptor index="3" class="com.mycompany.CustomInterceptor1"/> <interceptor before="org.infinispanpan.interceptors.CallInterceptor" class="com.mycompany.CustomInterceptor2"/> <interceptor after="org.infinispanpan.interceptors.CallInterceptor" class="com.mycompany.CustomInterceptor1"/> </customInterceptors> </namedCache>
注記
17.3.2. カスタムインターセプターをプログラミングにより追加
AdvancedCache
への参照を取得します。
CacheManager cm = getCacheManager(); Cache aCache = cm.getCache("aName"); AdvancedCache advCache = aCache.getAdvancedCache();
addInterceptor()
メソッドを使用してインターセプターを追加します。
advCache.addInterceptor(new MyInterceptor(), 0);
第18章 トランザクション
18.1. Java トランザクション API のトランザクションについて
- 最初に、現在スレッドに関連付けされているトランザクションを読み出します。
XAResource
が登録されていない場合は、XAResource
をトランザクションマネージャーに登録し、トランザクションがコミットされたりロールバックされた時に通知を受け取るようにします。
重要
ExceptionTimeout
のエラーが発生し、Unable to acquire lock after {time} on key {key} for requester {thread}
という警告が表示された場合は、トランザクションを有効にします。これは、非トランザクションキャッシュが書き込む各ノードに対するロックを取得するため、起こります。トランザクションを使用すると、キャッシュが単一ノードに対するロックを取得するため、デッドロックが回避されます。
18.2. 複数のキャッシュインスタンスにわたるトランザクション
18.3. トランザクション / バッチ処理および無効化メッセージ
18.4. トランザクションマネージャー
18.4.1. JTA トランザクションマネージャーのルックアップクラスについて
TransactionManagerLookup
インターフェースの実装に属するクラス名を用いて、キャッシュを設定します。キャッシュが初期化されると、指定クラスのインスタンスが作成されます。そして getTransactionManager()
メソッドを呼び出してトランザクションマネージャーへの参照を見つけ、返します。
DummyTransactionManagerLookup
はテスト目的でトランザクションマネージャーを提供します。このテスト向けのトランザクションマネージャーは実稼働環境では使用されず、特に並列トランザクションやリカバリーなどの機能は厳しく制限されます。JBossStandaloneJTAManagerLookup
は、JBoss Data Grid がスタンドアロン環境を実行する場合のデフォルトのトランザクションマネージャーです。これにより、JBoss Transactions ベースの完全に機能するトランザクションマネージャーで、DummyTransactionManagerLookup
の機能制限が解消されます。GenericTransactionManagaerLookup
は、ほとんどの Java EE アプリケーションサーバーでトランザクションマネージャーを見つけるために使用されるルックアップクラスです。デフォルトはDummyTransactionManagerLookup
です。JBossTransactionManagerLookup
は、JBoss Application Server インスタンス内でトランザクションマネージャーを見つけるルックアップクラスです。
注記
18.4.2. トランザクションマネージャーの使用
18.4.2.1. キャッシュからのトランザクションマネージャーの取得
手順18.1 キャッシュからのトランザクションマネージャーの取得
BasicCacheContainer
の設定場所プロパティーに次のプロパティーを追加して、transactionManagerLookupClass
を定義します。Configuration config = new ConfigurationBuilder() ... .transaction().transactionManagerLookup(new GenericTransactionManagerLookup())
TransactionManagerLookup.getTransactionManager
を次のように呼び出します。TransactionManager tm = cache.getAdvancedCache().getTransactionManager();
18.4.2.2. トランザクションの設定
<cache> .. <transaction mode="NONE" stop-timeout="30000" locking="OPTIMISTIC" /> ... </cache>
mode
属性はキャッシュトランザクションモードを設定します。この属性の有効な値はNONE
(デフォルト)、NON_XA
、NON_DURABLE_XA
、FULL_XA
です。stop-timeout
属性は、キャッシュが停止した時に JBoss Data Grid が継続するリモートおよびローカルトランザクションを待機する期間 (ミリ秒数) を示します。locking
属性はキャッシュに対して使用されるロックモードを指定します。この属性に有効な値はOPTIMISTIC
(デフォルト) とPESSIMISTIC
です。
18.4.2.3. トランザクションマネージャーと XAResources
XAResource
実装への参照を提供し、XAResource.recover
を実行する必要があります。
18.4.2.4. XAResource の参照の取得
XAResource
への参照を取得するには、次の API を使用します。
XAResource xar = cache.getAdvancedCache().getXAResource();
18.4.2.5. デフォルトの分散トランザクションの挙動
XAResource
より分散トランザクションで JBoss Data Grid を最初のクラス参加者として登録するのがデフォルトの挙動になります。JBoss Data Grid がトランザクションの参加者になる必要がない場合、同期化を介してトランザクションのライフサイクル状態 (準備、完了など) に関して通知することができます。
18.5. トランザクションの同期化
18.5.1. トランザクション (JTA) 同期化について
XAResource
として登録しなくても、JBoss Data Grid がトランザクションイベントへ応答できるようになります。その結果、トランザクションマネージャーがトランザクション操作を最適化し、2 相コミット (2PC) アルゴリズムではなく、1 相コミット (1PC) アルゴリズムが必要となります。
18.5.2. 同期化を有効にする
NONE
(同期)NO_XA
(同期)
注記
18.6. ステートの調整
18.6.1. ステートの調整について
18.6.2. トランザクションリカバリーについて
18.6.3. トランザクションリカバリーを有効にする
次のように XML 設定を使用し、トランザクションリカバリーを有効にします。
<transaction useEagerLocking="true" eagerLockSingleNode="true"> <recovery enabled="true" recoveryInfoCacheName="noRecovery"/> </transaction>
recoveryInfoCacheName
属性は任意です。
次のように Fluent Configuration API を介してトランザクションリカバリーを有効にすることもできます。
手順18.2 プログラミングによるトランザクションリカバリーの設定
- JBoss Data Grid のトランザクションリカバリーを有効にするには
.recovery
を呼び出します。configuration.fluent().transaction().recovery();
- トランザクションリカバリーの状態を確認するには、次のプログラミング設定を使用します。
boolean isRecoveryEnabled = configuration.isTransactionRecoveryEnabled();
- JBoss Data Grid のトランザクションリカバリーを無効にするには、次のプログラミング設定を使用します。
configuration.fluent().transaction().recovery().disable();
18.6.4. トランザクションリカバリーのプロセス
手順18.3 トランザクションリカバリーのプロセス
- トランザクションマネージャーは介入が必要なトランザクションの一覧を作成します。
- 電子メールまたはログを使用して、JMX を使用して JBoss Data Grid に接続するシステム管理者へトランザクション (トランザクション ID を含む) の一覧を提供します。各トランザクションの状態は
COMMITTED
かPREPARED
になります。COMMITTED
とPREPARED
の両方の状態であるトランザクションがある場合、ノード上で準備状態である間にトランザクションが他のノードでコミットされたことを意味します。 - システム管理者は、トランザクションマネージャーより受信した XID を JBoss Data Grid の内部 ID へ視覚的にマッピングします。XID (バイトアレイ) を JMX ツールに渡し、このマッピングがない状態で JBoss Data Grid によって再アセンブルすることはできないため、この手順が必要となります。
- マッピングされた内部 ID を基に、システム管理者はトランザクションに対してコミットまたはロールバックプロセスを強制します。
18.6.5. トランザクションリカバリーの例
例18.1 データベースに格納された口座から JBoss Data Grid 内の口座への送金
- 送信元 (データベース) と送信先 (JBoss Data Grid) リソース間の 2 フェーズコミットプロトコルを実行するために、
TransactionManager.commit()
メソッドが呼び出されます。 TransactionManager
が、準備フェーズ (2 フェーズコミットの最初のフェーズ) を開始するようデータベースと JBoss Data Grid に指示します。
18.6.7. 強制コミットおよびロールバック操作
18.6.8. トランザクションおよび例外
CacheException
(または、CacheException
のサブクラス) を返すと、トランザクションはロールバックするよう自動的にマークされます。
18.7. デッドロックの検出
18.7.1. デッドロックの検出について
disabled
に設定されます。
18.7.2. デッドロック検出を有効にする
disabled
に設定されていますが、以下を追加して namedCache
設定要素を使用すると、デッドロック検出を有効にし、各キャッシュに対して設定を行うことが可能です。
<deadlockDetection enabled="true" spinDuration="1000"/>
注記
第19章 マーシャリング
19.1. マーシャリングについて
19.2. マーシャリングの利点
- クラスター内の他の JBoss Data Grid ノードへ送信するため、データを変換します。
- 基礎のキャッシュストアに格納するためデータを変換します。
19.3. マーシャリングフレームワークについて
java.io.ObjectOutputStream
および java.io.ObjectInputStream
よりも高パフォーマンスな java.io.ObjectOutput
および java.io.ObjectInput
実装を使用します。
19.4. シリアライズ不可能なオブジェクトのサポート
Serializable
または Externalizable
サポートをクラスに導入できない場合、一例として XStream を使用してシリアライズ不可能なオブジェクトを JBoss Data Grid に格納できる文字列に変換し、対応することもできます。
注記
19.5. トラブルシューティング
19.5.1. マーシャリングのトラブルシューティング
java.io.NotSerializableException: java.lang.Object at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:857) at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:407) at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeObject(ReplicableCommandExternalizer.java:54) at org.infinispan.marshall.jboss.ConstantObjectTable$ExternalizerAdapter.writeObject(ConstantObjectTable.java:267) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:143) at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:407) at org.infinispan.marshall.jboss.JBossMarshaller.objectToObjectStream(JBossMarshaller.java:167) at org.infinispan.marshall.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:92) at org.infinispan.marshall.VersionAwareMarshaller.objectToByteBuffer(VersionAwareMarshaller.java:170) at org.infinispan.marshall.VersionAwareMarshallerTest.testNestedNonSerializable(VersionAwareMarshallerTest.java:415) Caused by: an exception which occurred: in object java.lang.Object@b40ec4 in object org.infinispan.commands.write.PutKeyValueCommand@df661da7 ... Removed 22 stack frames
java.lang.Object@b40ec4
はシリアライズ可能でないため、org.infinispan.commands.write.PutKeyValueCommand
インスタンス内の java.lang.Object
インスタンスはシリアライズできないことを示しています。
DEBUG
または TRACE
ロギングレベルが有効である場合、スタックトレースにあるオブジェクトの toString()
表現がマーシャリング例外に含まれます。このような状況を表す例は次の通りです。
java.io.NotSerializableException: java.lang.Object ... Caused by: an exception which occurred: in object java.lang.Object@b40ec4 -> toString = java.lang.Object@b40ec4 in object org.infinispan.commands.write.PutKeyValueCommand@df661da7 -> toString = PutKeyValueCommand{key=k, value=java.lang.Object@b40ec4, putIfAbsent=false, lifespanMillis=0, maxIdleTimeMillis=0}
java.io.IOException: Injected failue! at org.infinispan.marshall.VersionAwareMarshallerTest$1.readExternal(VersionAwareMarshallerTest.java:426) at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1172) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:273) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:210) at org.jboss.marshalling.AbstractUnmarshaller.readObject(AbstractUnmarshaller.java:85) at org.infinispan.marshall.jboss.JBossMarshaller.objectFromObjectStream(JBossMarshaller.java:210) at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:104) at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:177) at org.infinispan.marshall.VersionAwareMarshallerTest.testErrorUnmarshalling(VersionAwareMarshallerTest.java:431) Caused by: an exception which occurred: in object of type org.infinispan.marshall.VersionAwareMarshallerTest$1
org.infinispan.marshall.VersionAwareMarshallerTest$1
のインスタンスがアンマーシャリングされた時に IOException
がスローされます。
DEBUG
または TRACE
ロギングレベルが有効な場合、マーシャリング例外と似た方法で、クラスタイプのクラスローダー情報が提供されます。このクラスローダー情報の例は次の通りです。
java.io.IOException: Injected failue! ... Caused by: an exception which occurred: in object of type org.infinispan.marshall.VersionAwareMarshallerTest$1 -> classloader hierarchy: -> type classloader = sun.misc.Launcher$AppClassLoader@198dfaf ->...file:/opt/eclipse/configuration/org.eclipse.osgi/bundles/285/1/.cp/eclipse-testng.jar ->...file:/opt/eclipse/configuration/org.eclipse.osgi/bundles/285/1/.cp/lib/testng-jdk15.jar ->...file:/home/galder/jboss/infinispan/code/trunk/core/target/test-classes/ ->...file:/home/galder/jboss/infinispan/code/trunk/core/target/classes/ ->...file:/home/galder/.m2/repository/org/testng/testng/5.9/testng-5.9-jdk15.jar ->...file:/home/galder/.m2/repository/net/jcip/jcip-annotations/1.0/jcip-annotations-1.0.jar ->...file:/home/galder/.m2/repository/org/easymock/easymockclassextension/2.4/easymockclassextension-2.4.jar ->...file:/home/galder/.m2/repository/org/easymock/easymock/2.4/easymock-2.4.jar ->...file:/home/galder/.m2/repository/cglib/cglib-nodep/2.1_3/cglib-nodep-2.1_3.jar ->...file:/home/galder/.m2/repository/javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.jar ->...file:/home/galder/.m2/repository/javax/xml/stream/stax-api/1.0-2/stax-api-1.0-2.jar ->...file:/home/galder/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar ->...file:/home/galder/.m2/repository/jgroups/jgroups/2.8.0.CR1/jgroups-2.8.0.CR1.jar ->...file:/home/galder/.m2/repository/org/jboss/javaee/jboss-transaction-api/1.0.1.GA/jboss-transaction-api-1.0.1.GA.jar ->...file:/home/galder/.m2/repository/org/jboss/marshalling/river/1.2.0.CR4-SNAPSHOT/river-1.2.0.CR4-SNAPSHOT.jar ->...file:/home/galder/.m2/repository/org/jboss/marshalling/marshalling-api/1.2.0.CR4-SNAPSHOT/marshalling-api-1.2.0.CR4-SNAPSHOT.jar ->...file:/home/galder/.m2/repository/org/jboss/jboss-common-core/2.2.14.GA/jboss-common-core-2.2.14.GA.jar ->...file:/home/galder/.m2/repository/org/jboss/logging/jboss-logging-spi/2.0.5.GA/jboss-logging-spi-2.0.5.GA.jar ->...file:/home/galder/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar ->...file:/home/galder/.m2/repository/com/thoughtworks/xstream/xstream/1.2/xstream-1.2.jar ->...file:/home/galder/.m2/repository/xpp3/xpp3_min/1.1.3.4.O/xpp3_min-1.1.3.4.O.jar ->...file:/home/galder/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1.3/jaxb-impl-2.1.3.jar -> parent classloader = sun.misc.Launcher$ExtClassLoader@1858610 ->...file:/usr/java/jdk1.5.0_19/jre/lib/ext/localedata.jar ->...file:/usr/java/jdk1.5.0_19/jre/lib/ext/sunpkcs11.jar ->...file:/usr/java/jdk1.5.0_19/jre/lib/ext/sunjce_provider.jar ->...file:/usr/java/jdk1.5.0_19/jre/lib/ext/dnsns.jar ... Removed 22 stack frames
19.5.2. ステートレシーバーの EOFExceptions
2010-12-09 10:26:21,533 20267 ERROR [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (STREAMING_STATE_TRANSFER-sender-1,Infinispan-Cluster,NodeJ-2368:) Caught while responding to state transfer request org.infinispan.statetransfer.StateTransferException: java.util.concurrent.TimeoutException: Could not obtain exclusive processing lock at org.infinispan.statetransfer.StateTransferManagerImpl.generateState(StateTransferManagerImpl.java:175) at org.infinispan.remoting.InboundInvocationHandlerImpl.generateState(InboundInvocationHandlerImpl.java:119) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.getState(JGroupsTransport.java:586) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:691) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:772) at org.jgroups.JChannel.up(JChannel.java:1465) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:954) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:478) at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateProviderHandler.process(STREAMING_STATE_TRANSFER.java:653) at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateProviderThreadSpawner$1.run(STREAMING_STATE_TRANSFER.java:582) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Caused by: java.util.concurrent.TimeoutException: Could not obtain exclusive processing lock at org.infinispan.remoting.transport.jgroups.JGroupsDistSync.acquireProcessingLock(JGroupsDistSync.java:71) at org.infinispan.statetransfer.StateTransferManagerImpl.generateTransactionLog(StateTransferManagerImpl.java:202) at org.infinispan.statetransfer.StateTransferManagerImpl.generateState(StateTransferManagerImpl.java:165) ... 12 more
EOFException
をログに表示します。
2010-12-09 10:26:21,535 20269 TRACE [org.infinispan.marshall.VersionAwareMarshaller] (Incoming-2,Infinispan-Cluster,NodeI-38030:) Log exception reported java.io.EOFException: Read past end of file at org.jboss.marshalling.AbstractUnmarshaller.eofOnRead(AbstractUnmarshaller.java:184) at org.jboss.marshalling.AbstractUnmarshaller.readUnsignedByteDirect(AbstractUnmarshaller.java:319) at org.jboss.marshalling.AbstractUnmarshaller.readUnsignedByte(AbstractUnmarshaller.java:280) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:207) at org.jboss.marshalling.AbstractUnmarshaller.readObject(AbstractUnmarshaller.java:85) at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:175) at org.infinispan.marshall.VersionAwareMarshaller.objectFromObjectStream(VersionAwareMarshaller.java:184) at org.infinispan.statetransfer.StateTransferManagerImpl.processCommitLog(StateTransferManagerImpl.java:228) at org.infinispan.statetransfer.StateTransferManagerImpl.applyTransactionLog(StateTransferManagerImpl.java:250) at org.infinispan.statetransfer.StateTransferManagerImpl.applyState(StateTransferManagerImpl.java:320) at org.infinispan.remoting.InboundInvocationHandlerImpl.applyState(InboundInvocationHandlerImpl.java:102) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.setState(JGroupsTransport.java:603) ...
第20章 JGroups インターフェース
20.1. JGroups インターフェースについて
20.2. JGroups インターフェースの設定
bind_addr
プロパティーをキーワードに設定します。ドット付き 10 進法または記号の IP アドレスは用いません。
<socket-binding name="jgroups-udp" ... interface="site-local"/>
<interfaces> <interface name="link-local"><link-local-address/></interface> <interface name="site-local"><site-local-address/></interface> <interface name="global"><any-address/></interface> <interface name="non-loopback"><not><loopback/></not></interface> </interfaces>
link-local
:169.x.x.x
または254.x.x.x
アドレスを使用します。1 つのボックス内のトラフィックに適しています。site-local
:192.168.x.x
のようなプライベート IP アドレスを使用します。これにより、GoGrid や同様のプロバイダーより課金される追加の帯域幅が発生しないようにします。global
: パブリック IP アドレスを選択します。レプリケーショントラフィックへ使用しないようにしてください。non-loopback
:127.x.x.x
以外のアドレスで、アクティブなインターフェースで最初に見つかったアドレスを使用します。
20.3. ソケットのバインディグについて
20.3.1. グループおよび個別のソケットバインディングについて
20.3.2. 単一のソケットをバインドする例
socket-binding
要素を用いて個別のソケットをバインドする例を表しています。
<socket-binding name="jgroups-udp" ... interface="site-local"/>
20.3.3. ソケットのグループをバインドする例
socket-binding-group
要素を用いてグループをバインドする例を表しています。
<socket-binding-group name="ha-sockets" default-interface="global"> ... </socket-binding-group>
20.4. クラスターモードの JGroups
20.4.1. クラスタモードにおける JGroups の設定
GlobalConfiguration gc = new GlobalConfigurationBuilder() .transport() .defaultTransport() // <<< This call is missing... .addProperty("configurationFile","jgroups.xml") .build();
<infinispan> <global> <transport> <properties> <property name="configurationFile" value="jgroups.xml" /> </properties> </transport> </global> ... </infinispan>
jgroups.xml
を探します。
20.4.2. 事前設定された JGroups ファイル
20.4.2.1. 事前設定された JGroups ファイルの使用
infinispan-core.jar
にパッケージ化され、デフォルトでクラスパス上にて使用可能です。これらのいずれかのファイルを使用するには、jgroups.xml
を使用する代わりに使用するファイルの名前を指定します。
jgroups-udp.xml
jgroups-tcp.xml
20.4.2.2. jgroups-udp.xml
jgroups-udp.xml
は JBoss Data Grid の事前設定された JGroups ファイルです。
jgroups-udp.xml
設定は UDP をトランスポートとして使用し、UDP マルチキャストをディスカバリーに使用します。jgroups-udp.xml
設定は大型のクラスター (101 以上のノード) に適しています。jgroups-udp.xml
設定は、無効化またはレプリケーションモードを使用する場合に適しています。- ソケットの非効率な使用を最小限にします。
表20.1 jgroups-udp.xml システムプロパティー
システムプロパティー | 説明 | デフォルト | 必要性 |
---|---|---|---|
jgroups.udp.mcast_addr | マルチキャスト (通信とディスカバリーの両方) に使用する IP アドレス。IP マルチキャストに適した有効なクラス D IPアドレスでなければなりません。 | 228.6.7.8 | 不要 |
jgroups.udp.mcast_port | マルチキャストに使用するポート | 46655 | 不要 |
jgroups.udp.ip_ttl | IP マルチキャストパケットの TTL (有効期間) を指定します。この値は、パケットがドロップされる前に許可されるネットワークホップの数になります。 | 2 | 不要 |
20.4.2.3. jgroups-tcp.xml
jgroups-tcp.xml
は JBoss Data Grid の事前設定された JGroups ファイルです。
jgroups-tcp.xml
設定は TCP をトランスポートとして使用し、UDP マルチキャストをディスカバリーに使用します。jgroups-tcp.xml
設定は、ディストリビューションモードを使用している場合のみ、小型のクラスター (100 ノード未満) への使用に適しています。これは、TCP はポイントツーポイントプロトコルとしての方が効率が良いからです。
表20.2 jgroups-udp.xml システムプロパティー
システムプロパティー | 説明 | デフォルト | 必要性 |
---|---|---|---|
jgroups.tcp.address | TCP トランスポートに使用する IP アドレス。 | 127.0.0.1 | 不要 |
jgroups.tcp.port | TCP ソケットに使用するポート | 7800 | 不要 |
jgroups.udp.mcast_addr | マルチキャスト (ディスカバリーのため) に使用する IP アドレス。IP マルチキャストに適した有効なクラス D IPアドレスでなければなりません。 | 228.6.7.8 | 不要 |
jgroups.udp.mcast_port | マルチキャストに使用するポート | 46655 | 不要 |
jgroups.udp.ip_ttl | IP マルチキャストパケットの TTL (有効期間) を指定します。この値は、パケットがドロップされる前に許可されるネットワークホップの数になります。 | 2 | 不要 |
第21章 JBoss Data Grid の管理ツール
21.1. JMX (Java Management Extensions)
21.1.1. Java Management Extensions (JMX) について
MBeans
によって管理および監視されます。
21.1.2. JBoss Data Grid における JMX の使用
21.1.3. JMX 統計レベル
- 個別のキャッシュインスタンスによって管理情報が生成されるキャッシュレベル。
CacheManager
レベル。このレベルでは、CacheManager
エンティティーがCacheManager
より作成されたすべてのキャッシュインスタンスを管理します。そのため、管理情報は個別のキャッシュではなく、これらすべてのキャッシュインスタンスに対して生成されます。
21.1.4. キャッシュインスタンスに対して JMX を有効にする
デフォルトキャッシュインスタンスに対する <default> 要素内または特定の名前付きキャッシュに対するターゲット <namedCache> 要素下に、次のスニペットを追加します。
<jmxStatistics enabled="true"/>
プログラムを用いて JMX をキャッシュレベルで有効にするには、以下のコードを追加します。
Configuration configuration = ... configuration.setExposeJmxStatistics(true);
21.1.5. CacheManagers に対して JMX を有効にする
CacheManager
レベルでは、次のように宣言的またはプログラムを用いて JMX 統計を有効にすることができます。
次の <global> 要素を追加して、CacheManager
レベルで JMX を宣言的に有効にします。
<globalJmxStatistics enabled="true"/>
次のコードを追加して、プログラムを用いて JMX を CacheManager
で有効にします。
GlobalConfiguration globalConfiguration = ... globalConfiguration.setExposeGlobalJmxStatistics(true);
21.1.6. 複数の JMX ドメイン
CacheManager
インスタンスが 1 つの仮想マシンに存在したり、キャッシュインスタンスの名前が CacheManager
クラスと異なる場合に、JMX ドメインが複数使用されます。
CacheManager
に付けるようにします。
次のスニペットを関係する CacheManager
設定に追加します。
<globalJmxStatistics enabled="true" cacheManagerName="Hibernate2LC"/>
次のコードを追加し、プログラムを用いて CacheManager
の名前を設定します。
GlobalConfiguration globalConfiguration = ... globalConfiguration.setExposeGlobalJmxStatistics(true); globalConfiguration.setCacheManagerName("Hibernate2LC");
21.1.7. MBean について
MBean
は、サービス、コンポーネント、デバイス、またはアプリケーションなどの管理可能なリソースを表します。
MBeans
を提供します。例えば、トランスポート層で統計を提供する MBeans
などが提供されます。JBoss Data Grid サーバーは、JMX 統計で設定されます。JMX 統計はホスト名、ポート、読み取りバイト、書き込みバイト、およびワーカースレッドの数を提供する MBean
で、次の場所に存在します。
jboss.infinispan:type=Server,name=<Memcached|Hotrod>,component=Transport
21.1.8. MBean を理解する
MBean
を使用できます。
- キャッシュマネージャーレベルの JMX 統計が有効になっている場合、
jboss.infinispan:type=CacheManager,name="DefaultCacheManager"
という名前のMBean
が存在し、キャッシュマネージャーMBean
によってプロパティーが指定されます。 - キャッシュレベルの JMX 統計が有効になっている場合、使用される設定に応じて複数の
MBean
が表示されます。例えば、ライトビハインドキャッシュストアが設定されている場合、キャッシュストアコンポーネントに属するプロパティーを公開するMBean
が表示されます。すべてのキャッシュレベルMBeans
は同じ形式を使用します。jboss.infinispan:type=Cache,name="<name-of-cache>(<cache-mode>)",manager="<name-of-cache-manager>",component=<component-name>
この形式の詳細は次の通りです。cache-container
要素のdefault-cache
属性を使用してキャッシュのデフォルト名を指定します。cache-mode
はキャッシュのキャッシュモードに置き換えられます。可能な列挙値を小文字にしたものがキャッシュモードを表します。component-name
は、 JMX 参考ドキュメントにある JMX コンポーネント名の 1 つに置き換えられます。
MBean
は次のように命名されます。
jboss.infinispan:type=Cache,name="default(dist_sync)", manager="default",component=CacheStore
21.1.9. デフォルトでない MBean サーバーでの MBean の登録
getMBeanServer()
メソッドが希望の (デフォルト以外の) MBeanServer を返すようにします。
次のスニペットを追加します。
<globalJmxStatistics enabled="true" mBeanServerLookup="com.acme.MyMBeanServerLookup"/>
次のコードを追加します。
GlobalConfiguration globalConfiguration = ... globalConfiguration.setExposeGlobalJmxStatistics(true); globalConfiguration.setMBeanServerLookup("com.acme.MyMBeanServerLookup")
21.2. JON (JBoss Operations Network)
21.2.1. JBoss Operations Network (JON) について
21.2.2. JBoss Operations Network (JON) および JMX
21.2.3. JBoss Operations Network (JON) の設定
手順21.1 JBoss Operations Network の設定
- JBoss Operations Network をダウンロードしてインストールし、1 つ以上の JBoss Operations Network エージェントを初期化します。JBoss Operations Network エージェントは、JBoss Data Grid インスタンスに関する情報をサーバーへ送信する役割があります。サーバーは受信した情報を GUI を使用して表示します。JBoss Data Grid を実行するマシンに JBoss Operations Network エージェントをインストールすることが推奨設定となります。複数のマシンが使用できる場合、エージェントは各マシン上に存在することができます。
- 最新の JBoss Data Grid のバージョンをダウンロードします。
modules/rhq-plugin
ディレクトリで JBoss Operations Network のプラグイン jar ファイル (infinispan-rhq-plugin.jar
) を見つけます。 - これで、JBoss Operations Network が JBoss Data Grid インスタンスを監視できるようにします。
- JBoss Operations Network は各 JBoss Data Grid インスタンスを見つけた後、各キャッシュマネージャーに対して新しいリソースを JBoss Operations Network サーバーのインベントリー / ディスカバリーキューに表示します。
- 表示されたリソースをインポートします。キャッシュマネージャーはキャッシュマネージャーで実行されているキャッシュの数だけ、子キャッシュリソースを表示します。
JBoss Operations Network を使用して JBoss Data Grid を監視できるようになります。
21.2.4. JBoss Operations Network のプラグインクイックスタート
21.2.5. リモート JMX ポートの値
付録A 参照
A.1. Apache Lucene Index について
A.2. 一貫性について
A.3. 一貫性保証について
- キー
K
はノード{A,B}
へハッシュ化されます。トランザクションTX1
は、例えばノードA
上のK
ロックを取得します。 - 他のキャッシュへのアクセスが、ノード
B
または他のノードで発生すると、TX2
がK
をロックしようとしますが、トランザクションTX1
が既にK
のロックを保持しているため、タイムアウトが発生しロックの取得に失敗します。
K
のロックはトランザクションの発生元に関係なく、常にクラスターの同じノード上で取得されるため、このロックの取得は常に失敗します。
A.4. Java Management Extensions (JMX) について
MBeans
によって管理および監視されます。
A.5. JBoss Cache について
A.6. JSON について
A.7. 戻り値について
A.8. 実行可能インターフェースについて
run()
メソッドを宣言します。実行可能オブジェクトは、スレッドコンストラクターに渡された後、独自のスレッドでの実行が可能です。
A.9. 2 相コミット (2PC) について
A.10. キーバリューペアについて
- キーは特定のデータエントリーに一意であり、関連する特定エントリーのデータ属性によって構成されます。
- バリュー (値) は、キーによって割り当てられ、キーによって識別されるデータです。
A.11. エクスターナライザー
A.11.1. エクスターナライザーについて
Externalizer
クラスは、以下のことを行えるクラスです。
- 該当するオブジェクトタイプをバイトアレイにマーシャリングします。
- バイトアレイの内容をオブジェクトタイプのインスタンスにマーシャリング解除します。
A.11.2. 内部エクスターナライザー実装アクセス
public static class ABCMarshallingExternalizer implements AdvancedExternalizer<ABCMarshalling> { @Override public void writeObject(ObjectOutput output, ABCMarshalling object) throws IOException { MapExternalizer ma = new MapExternalizer(); ma.writeObject(output, object.getMap()); } @Override public ABCMarshalling readObject(ObjectInput input) throws IOException, ClassNotFoundException { ABCMarshalling hi = new ABCMarshalling(); MapExternalizer ma = new MapExternalizer(); hi.setMap((ConcurrentHashMap<Long, Long>) ma.readObject(input)); return hi; } ...
public static class ABCMarshallingExternalizer implements AdvancedExternalizer<ABCMarshalling> { @Override public void writeObject(ObjectOutput output, ABCMarshalling object) throws IOException { output.writeObject(object.getMap()); } @Override public ABCMarshalling readObject(ObjectInput input) throws IOException, ClassNotFoundException { ABCMarshalling hi = new ABCMarshalling(); hi.setMap((ConcurrentHashMap<Long, Long>) input.readObject()); return hi; } ... }
A.12. ハッシュ領域の割り当て
A.12.1. ハッシュ領域の割り当てについて
A.12.2. ハッシュ領域におけるキーの検索
A.12.3. 完全なバイトアレイの要求
デフォルトでは、必要のない巨大なバイトアレイを出力しないように、JBoss Data Grid はバイトアレイの一部のみをログに出力します。以下の場合にバイトアレイがログに出力されます。
- JBoss Data Grid のキャッシュにレイジーデシリアライゼーションが設定されている場合。レイジーデシリアライゼーションは JBoss Data Grid のリモートクライアントサーバーモードでは使用できません。
Memcached
またはHot Rod
サーバーが実行されている場合。
-Dinfinispan.arrays.debug=true
システムプロパティーを渡します。
例A.1 部分的なバイトアレイのログ
2010-04-14 15:46:09,342 TRACE [ReadCommittedEntry] (HotRodWorker-1-1) Updating entry (key=CacheKey{data=ByteArray{size=19, hashCode=1b3278a, array=[107, 45, 116, 101, 115, 116, 82, 101, 112, 108, ..]}} removed=false valid=true changed=true created=true value=CacheValue{data=ByteArray{size=19, array=[118, 45, 116, 101, 115, 116, 82, 101, 112, 108, ..]}, version=281483566645249}] And here's a log message where the full byte array is shown: 2010-04-14 15:45:00,723 TRACE [ReadCommittedEntry] (Incoming-2,Infinispan-Cluster,eq-6834) Updating entry (key=CacheKey{data=ByteArray{size=19, hashCode=6cc2a4, array=[107, 45, 116, 101, 115, 116, 82, 101, 112, 108, 105, 99, 97, 116, 101, 100, 80, 117, 116]}} removed=false valid=true changed=true created=true value=CacheValue{data=ByteArray{size=19, array=[118, 45, 116, 101, 115, 116, 82, 101, 112, 108, 105, 99, 97, 116, 101, 100, 80, 117, 116]}, version=281483566645249}]
付録B 改訂履歴
改訂履歴 | |||
---|---|---|---|
改訂 1.0.0-29 | Mon Feb 03 2014 | Misha Husnain Ali | |
|