インターフェイスは、エンドポイントをネットワークの場所にバインドします。

Data Grid Server 7.x ネットワークインターフェイスの設定

Data Grid 7.x では、サーバー設定でさまざまなインターフェイスを使用して、管理アクセスと管理アクセスをキャッシュアクセスから分離していました。

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
</interfaces>

Data Grid Server 8 ネットワークインターフェイスの設定

Data Grid 8 には、管理アクセスと管理アクセス、およびキャッシュアクセス用のすべてのクライアント接続用に 1 つのネットワークインターフェイスがあります。

<interfaces>
  <interface name="public">
    <inet-address value="${infinispan.bind.address:127.0.0.1}"/>
  </interface>
</interfaces>

ソケットバインディングは、エンドポイントがクライアント接続をリッスンするポートにネットワークインターフェイスをマップします。

Data Grid Server 7.x ソケットバインディングの設定

Data Grid 7.x では、サーバー設定は、管理コンソール用の 9990 やネイティブ管理プロトコル用のポート 9999 など、管理と管理に一意のポートを使用していました。古いバージョンでは、外部 Hot Rod アクセス用の 11222 や REST 用の 8080 など、エンドポイントごとに一意のポートも使用されていました。

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
  <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
  <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
  <socket-binding name="hotrod" port="11222"/>
  <socket-binding name="hotrod-internal" port="11223"/>
  <socket-binding name="hotrod-multi-tenancy" port="11224"/>
  <socket-binding name="memcached" port="11211"/>
  <socket-binding name="rest" port="8080"/>
  ...
</socket-binding-group>

Data Grid Server 8 の単一ポート設定

Data Grid 8 は、単一のポートを使用してサーバーへのすべての接続を処理します。Hot Rod クライアント、REST クライアント、Data Grid CLI、および Data GridConsole は すべてポート 11222 を使用します。

<socket-bindings default-interface="public"
                 port-offset="${infinispan.socket.binding.port-offset:0}">
  <socket-binding name="default" port="${infinispan.bind.port:11222}"/>
  <socket-binding name="memcached" port="11221"/>
</socket-bindings>

エンドポイントは、リモートクライアント接続をリッスンし、Hot Rod や HTTP (REST) などのプロトコルを介して要求を処理します。

Data Grid Server 7.x エンドポイントサブシステム

Data Grid 7.x では、endpoint サブシステムを使用して、HotRod および REST エンドポイントのコネクターを設定できます。

<subsystem xmlns="urn:infinispan:server:endpoint:9.4">
  <hotrod-connector socket-binding="hotrod" cache-container="local">
    <topology-state-transfer lazy-retrieval="false" lock-timeout="1000" replication-timeout="5000"/>
  </hotrod-connector>
  <rest-connector socket-binding="rest" cache-container="local">
    <authentication security-realm="ApplicationRealm" auth-method="BASIC"/>
  </rest-connector>
</subsystem>

Data Grid Server 8 エンドポイント設定

Data Grid 8 は、endpoint サブシステムを endpoint 要素に置き換えます。hotrod-connector と rest-connector の設定要素と属性は、以前のバージョンと同じです。

Data Grid 8.2 以降、デフォルトの endpoints 設定は、以下のように暗黙的な Hot Rod および REST コネクターを使用します。

<endpoints socket-binding="default" security-realm="default"/>

<endpoints socket-binding="default" security-realm="default">
  <hotrod-connector name="hotrod"/>
  <rest-connector name="rest"/>
</endpoints>

Data Grid Server 8.3 以降では、セキュリティーレルムを使用してエンドポイントを設定し、endpoint 要素を使用して Hot Rod または REST コネクターを設定します。endpoints 要素は、複数の endpoint 設定のラッパーになりました。

<endpoints>
  <endpoint socket-binding="public" security-realm="application-realm" admin="false">
    <hotrod-connector/>
    <rest-connector/>
  </endpoint>
  <endpoint socket-binding="private" security-realm="management-realm">
    <hotrod-connector/>
    <rest-connector/>
  </endpoint>
</endpoints>

Data Grid 8 では、セキュリティーレルムは暗黙の設定オプションを提供します。これは、以前のバージョンほど多くの設定を提供する必要がないことを意味します。たとえば、Kerberos レルムを定義すると、Kerberos 機能を利用できます。トラストストアを追加すると、証明書認証を取得します。

Data Grid 7.x には、2 つのデフォルトのセキュリティーレルムがありました。

一方、Data Grid 8 は、HotRod および REST エンドポイントに使用できる複数の異なるセキュリティーレルムを定義できる security 要素を提供します。

<security>
  <security-realms>
    ...
  </security-realms>
</security>

サポートされているセキュリティーレルム

サーバー ID は、証明書チェーンを使用して、データグリッドサーバー ID をリモートクライアントに証明します。

Data Grid 8 は、以前のバージョンと同じ設定を使用して SSL ID を定義しますが、使いやすさが向上しています。

<security-realm name="default">
  <server-identities>
    <ssl>
      <keystore path="..."
                relative-to="..."
                keystore-password="..."
                alias="..."
                key-password="..."
                generate-self-signed-certificate-host="..."/>
    </ssl>
  </server-identities>
  ...
<security-realm>

Hot Rod および REST エンドポイントは、SASL または HTTP メカニズムを使用してクライアント接続を認証します。

Data Grid 8 は、Data Grid 7.x 以前と同じ authentication 要素を hotrod-connector および rest-connector 設定に使用します。

<hotrod-connector name="hotrod">
  <authentication>
    <sasl mechanisms="..." server-name="..."/>
  </authentication>
</hotrod-connector>
<rest-connector name="rest">
  <authentication>
    <mechanisms="..." server-principal="..."/>
  </authentication>
</rest-connector>

以前のバージョンとの主な違いの 1 つは、Data Grid 8 がエンドポイントの追加の認証メカニズムをサポートしていることです。

Hot Rod SASL 認証メカニズム

Hot Rod クライアントは、DIGEST-MD5 ではなく SCRAM-SHA-512 をデフォルトの認証メカニズムとして使用するようになりました。

HTTP (REST) 認証メカニズム

EAP アプリケーションクラスパスの hotrod-client.properties にクレデンシャルを追加して、次の方法でデータグリッドで認証できるようになりました。

Data Grid は、JBoss Log Manager に基づいていた以前のバージョンのロギングサブシステムの代わりに Apache Log4j2 を使用します。

デフォルトでは、DataGrid はログメッセージを次のディレクトリーに書き込みます。
$RHDG_HOME/${infinispan.server.root}/log

server.log はデフォルトのログファイルです。

アクセスログ

以前のバージョンでは、Data Grid にキャッシュのセキュリティーログを監査するためのロガーが含まれていました。

<authorization audit-logger="org.infinispan.security.impl.DefaultAuditLogger">

Data Grid 8 は、この監査ロガーを提供しなくなりました。

ただし、Hot Rod エンドポイントと REST エンドポイントのログカテゴリーを使用できます。

リモートキャッシュを作成するときは、キーと値の MediaType を設定する必要があります。MediaType を設定すると、データのストレージ形式が保証されます。

キャッシュをエンコードするには、設定で MediaType を指定します。他の要件がない限り、ProtoStream を使用する必要があります。これは、言語に依存しない下位互換性のある形式でデータを格納します。

<encoding media-type="application/x-protostream"/>

<infinispan>
    <cache-container>
        <distributed-cache name="myCache" mode="SYNC">
          <encoding media-type="application/x-protostream"/>
           ...
        </distributed-cache>
    </cache-container>
</infinispan>

リモートキャッシュをエンコードしない場合、Data Grid Server は次のメッセージをログに記録します。

WARN  (main) [org.infinispan.encoding.impl.StorageConfigurationManager] ISPN000599: Configuration for cache 'mycache' does not define the encoding for keys or values. If you use operations that require data conversion or queries, you should configure the cache with a specific MediaType for keys or values.

将来のバージョンでは、データ変換が行われる操作にキャッシュエンコーディングが必要になります。たとえば、キャッシュのインデックス作成とデータコンテナーの検索、リモートタスクの実行、Hot Rod および REST エンドポイントからのさまざまな形式でのデータの読み取りと書き込み、リモートフィルター、コンバーター、リスナーの使用などです。

Data Grid 7.x には、クラスターのヘルスステータスとクラスター内のキャッシュを返すヘルスチェック API が含まれています。

Data Grid 8 は Health API も提供します。組み込みおよびサーバーインストールの場合、次の MBean を使用して JMX 経由で Health API にアクセスできます。

org.infinispan:type=CacheManager,name="default",component=CacheContainerHealth

Data Grid Server は、REST エンドポイントと Data Grid Console を介して Health API も公開します。

このトピックでは、8.0 から 8.1 までの Data Grid 設定スキーマへの変更を一覧表示します。

新規および変更された要素と属性

非推奨の要素と属性

次の要素と属性は非推奨になりました。

削除された要素と属性

次の要素と属性は以前のリリースで非推奨になり、現在は削除されています。

このトピックでは、8.1 から 8.2 までの Data Grid 設定スキーマへの変更を一覧表示します。

変更された要素と属性

新しい要素と属性

非推奨の要素と属性

Data Grid 8.2 では非推奨の要素や属性はありません。

削除された要素と属性

Data Grid 8.2 では要素や属性は削除されません。

このトピックでは、8.2 から 8.3 までの Data Grid 設定スキーマへの変更を一覧表示します。

スキーマの変更

変更された要素と属性

新しい要素と属性

非推奨の要素と属性

次の要素と属性は非推奨になりました。

削除された要素と属性

Data Grid スキーマでは、以下の要素および属性が利用できなくなりました。

Data Grid では、次のオプションを使用して、エントリーをメモリーに保存する方法を制御できます。

Data Grid 8 の変更

以前の 7.x バージョンおよび 8.0 では、object、binary、および off-heap 要素を使用してストレージタイプを設定していました。

Data Grid 8.1 以降では、storage 属性を使用して、オブジェクトを JVM ヒープメモリーに格納するか、バイトとしてオフヒープメモリーに格納します。

JVM ヒープメモリーにバイトを格納するには、encoding 要素を使用して、データのバイナリーストレージ形式を指定します。

Data Grid 8 のオブジェクトストレージ

デフォルトでは、Data Grid 8.1 はオブジェクトストレージ (JVM ヒープ) を使用します。

<distributed-cache>
   <memory />
</distributed-cache>

storage="HEAP" を明示的に設定して、データをオブジェクトとして JVM ヒープメモリーに格納することもできます。

<distributed-cache>
   <memory storage="HEAP" />
</distributed-cache>

Data Grid 8 のオフヒープストレージ

データをバイトとしてネイティブメモリーに保存するには、storage 属性の値として "OFF_HEAP" を設定します。

<distributed-cache>
   <memory storage="OFF_HEAP" />
</distributed-cache>

オフヒープアドレス数

以前のバージョンでは、offheap の address-count 属性を使用すると、衝突を回避するためにハッシュマップで使用可能なポインターの数を指定できます。Data Grid 8.1 では、address-count は使用されなくなり、オフヒープメモリーは衝突を回避するために動的にサイズ変更されます。

Data Grid 8 のバイナリーストレージ

encording 要素を使用して、キャッシュエントリーのバイナリーストレージ形式を指定します。

<distributed-cache>
   <!--Configure MediaType for entries with binary formats.-->
   <encoding media-type="application/x-protostream"/>
   <memory ... />
</distributed-cache>

エビクションを使用すると、コンテナーが設定されたしきい値より大きくなったときにエントリーを削除することで、Data Grid がデータコンテナーのサイズを制御できます。

Data Grid 7. x および 8.0 では、キャッシュ内のエントリーの最大制限を定義する 2 つのエビクションタイプを指定します。

設定した設定に応じて、メモリーの数または合計量のいずれかが最大値を超えると、Data Grid は未使用のエントリーを削除します。

Data Grid 7.x および 8.0 も長いようなデータコンテナーのサイズを規定する size 属性を使用します。設定するストレージの種類に応じて、エントリーの数またはメモリーの量が size 属性の値を超えると、エビクションが発生します。

Data Grid 8.1 では、size 属性は COUNT および MEMORY とともに非推奨になりました。代わりに、次の 2 つの方法のいずれかでデータコンテナーの最大サイズを設定します。

エントリーの総数に基づくエビクション

<distributed-cache>
   <memory max-count="..." />
</distributed-cache>

最大メモリー量に基づくエビクション

<distributed-cache>
   <memory max-size="..." />
</distributed-cache>

エビクション戦略は、Data Grid がエビクションを実行する方法を制御します。

Data Grid 7.x および 8.0 では、strategy 属性を使用して次のエビクション戦略のいずれかを設定できます。

Data Grid 8.1 では、以前のバージョンと同じ戦略を使用できます。ただし、strategy 属性は when-full 属性に置き換えられます。

<distributed-cache>
   <memory when-full="<eviction_strategy>" />
</distributed-cache>

エビクションアルゴリズム

Data Grid 7.2 では、エビクションアルゴリズムを設定する機能は、Low Inter-Reference Recency Set (LIRS) とともに非推奨になりました。

バージョン 7.2 以降、Data Grid には、TinyLFU と呼ばれる Least Frequently Used (LFU) キャッシュ置換アルゴリズムのバリエーションを実装する Caffeine キャッシングライブラリーが含まれています。オフヒープストレージの場合、Data Grid は LeastRecent Used (LRU) アルゴリズムのカスタム実装を使用します。

異なる Data Grid バージョン間でエビクション設定を比較します。

オブジェクトストレージとエントリー数の排除

7.2 から 8.0

<memory>
  <object size="1000000" eviction="COUNT" strategy="REMOVE"/>
</memory>

8.1

<memory max-count="1MB" when-full="REMOVE"/>

オブジェクトストレージとメモリー量の排除

7.2 から 8.0

<memory>
  <object size="1000000" eviction="MEMORY" strategy="MANUAL"/>
</memory>

8.1

<memory max-size="1MB" when-full="MANUAL"/>

バイナリーストレージとエントリー数の排除

7.2 から 8.0

<memory>
  <binary size="500000000" eviction="MEMORY" strategy="EXCEPTION"/>
</memory>

8.1

<cache>
   <encoding media-type="application/x-protostream"/>
   <memory max-size="500 MB" when-full="EXCEPTION"/>
</cache>

バイナリーストレージとメモリー量の排除

7.2 から 8.0

<memory>
  <binary size="500000000" eviction="COUNT" strategy="MANUAL"/>
</memory>

8.1

<memory max-count="500 MB" when-full="MANUAL"/>

オフヒープストレージとエントリー数の排除

7.2 から 8.0

<memory>
  <off-heap size="10000000" eviction="COUNT"/>
</memory>

8.1

<memory storage="OFF_HEAP" max-count="10MB"/>

オフヒープストレージとメモリー量の排除

7.2 から 8.0

<memory>
  <off-heap size="1000000000" eviction="MEMORY"/>
</memory>

8.1

<memory storage="OFF_HEAP" max-size="1GB"/>

キャッシュ設定に file-store 永続性を含めると、単一ファイルキャッシュストア SingleFileStore ではなく、soft index ファイルベースのキャッシュストア SoftIndexFileStore が作成されるようになりました。Data Grid 8.2 以前では、SingleFileStore はファイルベースのキャッシュストアのデフォルトでした。

以前のバージョンから DataGrid 8.3 に移行またはアップグレードしていて、キャッシュに soft-index-file-store 要素を含む設定が含まれている場合は、代わりに file-store 要素を使用するようにその設定を変換する必要があります。

<persistence>
  <soft-index-file-store xmlns="urn:infinispan:config:soft-index:12.1">
    <index path="testCache/index" />
    <data path="testCache/data" />
  </soft-index-file-store>
</persistence>

<persistence>
  <file-store>
    <index path="testCache/index" />
    <data path="testCache/data" />
  </file-store>
</persistence>

ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
    .addStore(SoftIndexFileStoreConfigurationBuilder.class)
        .indexLocation("testCache/index");
        .dataLocation("testCache/data")

ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
    .addSoftIndexFileStore()
        .indexLocation("testCache/index")
        .dataLocation("testCache/data");

<persistence passivation="false">
  <single-file-store shared="false"
                     preload="true"
                     fetch-state="true"
                     read-only="false"/>
</persistence>

ConfigurationBuilder b = new ConfigurationBuilder();
b.persistence()
    .addSingleFileStore();

以前のバージョンと同様に、Data Grid 8 は JGroups SYM_ENCRYPT および ASYM_ENCRYPT プロトコルを使用してクラスター通信を暗号化します。

Data Grid では、キーストアとトラストストアを TLS サーバーアイデンティティーとして含むセキュリティーレルムを使用して、クラスタートランスポートをセキュアにすることもできます。以下に例を示します。

<cache-container>
  <transport server:security-realm="tls-transport"/>
</cache-container>

Data Grid 8 以降、セキュリティーレルムに対してノード認証を設定することはできません。同様に、Data Grid 8 は、クラスター化されたノードの認証に JGroups AUTH プロトコルを使用することを推奨していません。

ただし、組み込みデータグリッドのインストールでは、JGroups クラスタートランスポートに jgroups 要素の一部として SASL 設定が含まれます。以前のバージョンと同様に、SASL 設定は、ノード認証に必要な特定の情報を取得するために、CallbackHandlers などの JAAS 概念に依存しています。

Data Grid 8.2 は、デフォルトの JGroups スタック内の UNICAST3 および NAKACK2 プロトコルの再送信要求の設定を次のように変更します。

Data Grid 8 への移行の一環として、これらの推奨設定を使用するようにカスタム JGroups スタック設定を調整する必要があります。

Data Grid 8.3 には、以下の REST API への変更が含まれています。

キャッシュの再インデックス設定

Data Grid キャッシュのインデックスを再作成するための mass-index 操作は非推奨になりました。以下の例のように、代わりに reindex を使用するようにクライアントを更新します。

/v2/caches/<cacheName>/search/indexes?action=reindex

ローリングアップグレード操作

以下の操作が非推奨になりました。

POST /v2/caches/<cacheName>?action=disconnect-source

代わりに source-connection 操作を使用してください。

DELETE /v2/caches/<cacheName>/rolling-upgrade/source-connection

Data Grid は、Hibernate および Apache Lucene ライブラリーをアップグレードして、Query API のパフォーマンスおよび機能を改善します。このアップグレードの一環として、Data Grid は新しいインデックス作成機能を導入し、いくつかの Hibernate および Lucene アノテーションを削除します。

クエリーの統計

Data Grid 8.2 は、以下のようにキャッシュ設定で統計を宣言的に有効にした場合にのみ、クエリーおよびインデックスの統計を公開します。

<replicated-cache name="myReplicatedCache" statistics="true">
  <!-- Cache configuration goes here. -->
</replicated-cache>

JMX 経由でのクエリーおよびインデックスの統計を有効にすることはできなくなりました。

Data Grid キャッシュのインデックス作成

インデックスマネージャー

Data Grid 8.2 は、デフォルトのインデックスマネージャーとして near-real-time を使用し、設定を必要としなくなりました。

インデックスリーダーおよびライター

Data Grid 8.2 では、インデックスを作成するための内部コンポーネントであるインデックスリーダーとインデックスライターが導入されています。

設定を適応させるには、次のことを行う必要があります。

インデックスストレージ

Data Grid 8.2 には、以前のバージョンの property 要素設定を置き換える storage 属性が含まれています。storage 属性を使用すると、インデックスを JVM ヒープに格納するかホストファイルシステムに格納するかを設定できます。

インデックスプロパティーの適応

インデックス設定を DataGrid 8.2 に移行するときは、次の変更も行う必要があります。

Hibernate および Lucene アノテーション

@Field、@Indexed、@SortableField などの Hibernate および Lucene アノテーションの移行については、Hibernate Search Migration Guide の Annotation mapping セクションを参照してください。

Data Grid 8.3 は IndexedQueryMode パラメーターを削除します。Data Grid は、キャッシュのクエリーに最適なモードを自動的に検出し、以前のバージョンでは任意のパラメーターを無視していました。

デフォルトでは、Data Grid 8 は ProtoStream API を使用して、言語に依存しない下位互換性のある形式である Protocol Buffers としてデータをマーシャリングします。

Protobuf エンコーディングはスキーマ定義のフォーマットであり、現在多くのアプリケーションのデフォルト標準であり、Data Grid 7 のデフォルトであった JBoss Marshalling と比較してデータをトランスコードする際の柔軟性が高くなっています。

ProtoStream マーシャラーは Protobuf 形式に基づいているため、DataGrid は最初に Java オブジェクトに変換せずに他のエンコーディングに変換できます。JBoss Marshalling を使用する場合、他の形式に変換する前に、キーと値を Java オブジェクトに変換する必要があります。

Data Grid 8 への移行の一環として、Java クラスに ProtoStream マーシャリングの使用を開始する必要があります。

高レベルから、ProtoStream マーシャラーを使用するには、ProtoStream プロセッサーを使用して SerializationContextInitializer 実装を生成します。まず、@Proto アノテーションを Java クラスに追加してから、Data Grid が提供する ProtoStream プロセッサーを使用して、以下を含むシリアル化コンテキストを生成します。

埋め込みキャッシュとリモートキャッシュのどちらを使用するかに応じて、Data Grid は SerializationContextInitializer 実装を自動的に登録できます。

ネストされた ProtoStream アノテーション

Data Grid 8.2 は ProtoStream 4.4.0.Final にアップグレードします。これには、場合によっては移行が必要です。

以前のバージョンでは、ProtoStream API は、メッセージが最上位としてのみ生成されたメッセージタイプを正しくネストしませんでした。

永続キャッシュストアに Protobuf でエンコードされたエントリーがある場合は、ProtoStream アノテーションがトップレベルになるように Java クラスを変更する必要があります。これにより、永続化されたメッセージのネストが Java クラスのネストと一致することが保証されます。一致しない場合、データの非互換性の問題が発生する可能性があります。

たとえば、次のようなネストされた Java クラスがある場合:

class OuterClass {
   class InnerClass {
       @ProtoField(1)
       int someMethod() {
       }
   }
}

InnerClass が OuterClass の子ではなくなるように、クラスを調整する必要があります。

class InnerClass {
    @ProtoField(1)
    int someMethod() {
    }
}

Data Grid サーバーとのマーシャリング

リモートキャッシュには Protobuf エンコーディングのみを使用し、カスタムタイプには ProtoStream マーシャラーを組み合わせて使用する必要があります。

JBoss マーシャリングなどの他のマーシャラー実装では、Data Grid CLI、Data Grid Console、または Ickle クエリーと互換性のない異なるキャッシュエンコーディングを使用する必要があります。

キャッシュストアと ProtoStream

Data Grid 7.x では、キャッシュストアに永続化するデータは、Data Grid 8 の ProtoStream マーシャラーと互換性がありません。データを DataGrid7.x キャッシュストアから Data Grid 8 キャッシュストアに移行するには、StoreMigrator ユーティリティーを使用する必要があります。

Data Grid は、ProtoStream の代替マーシャラー実装を提供し、古いバージョンからの移行を容易にします。これらの代替マーシャラーは、ProtoStream マーシャリングに移行する際の暫定的な解決策としてのみ使用する必要があります。

デシリアライズ許可リスト

Red Hat では、多様性を受け入れる用語の使用への取り組みに努めており、Java クラスのシリアル化を設定する際に使用するホワイトリストという用語を許可リストに変更しています。

<cache-container>
   <serialization>
      <white-list>
         <class>org.infinispan.test.data.Person</class>
         <regex>org.infinispan.test.data.*</regex>
       </white-list>
   </serialization>
</cache-container>

<cache-container>
   <serialization>
      <allow-list>
         <class>org.infinispan.test.data.Person</class>
         <regex>org.infinispan.test.data.*</regex>
       </allow-list>
   </serialization>
</cache-container>

JBoss marshalling

Data Grid 7 では、JBoss Marshalling がデフォルトのマーシャラーです。Data Grid 8 では、Proto Stream マーシャリングがデフォルトです。

Data Grid 8 への移行中に一時的な解決策として JBoss Marshalling を使用する必要がある場合は、以下を実行します。

次のように、JBoss Marshalling を使用するように Hot Rod Java クライアントを設定する必要があります。

この例には、デフォルト以外のタイプを使用するいくつかのフィールドが含まれています。コードジェネレーターはデフォルトで int 型を使用するため、text フィールドの順序は異なり、fixed32 フィールドは生成された Protobuf スキーマタイプと競合します。

public class SimpleEntry {

  private String description;
  private Collection<String> text;
  private int intDefault;
  private Integer fixed32;

  // public Getter, Setter, equals and HashCode methods omitted for brevity
}

import org.infinispan.protostream.MessageMarshaller;

public class SimpleEntryMarshaller implements MessageMarshaller<SimpleEntry> {

  @Override
  public void writeTo(ProtoStreamWriter writer, SimpleEntry testEntry) throws IOException {
    writer.writeString("description", testEntry.getDescription());
    writer.writeInt("intDefault", testEntry.getIntDefault());
    writer.writeInt("fix32", testEntry.getFixed32());
    writer.writeCollection("text", testEntry.getText(), String.class);
  }

  @Override
  public SimpleEntry readFrom(MessageMarshaller.ProtoStreamReader reader) throws IOException {
    SimpleEntry x = new SimpleEntry();

    x.setDescription(reader.readString("description"));
    x.setIntDefault(reader.readInt("intDefault"));
    x.setFixed32(reader.readInt("fix32"));
    x.setText(reader.readCollection("text", new LinkedList<String>(), String.class));

    return x;
  }
}

syntax = "proto2";

package example;

message SimpleEntry {
   required string description = 1;
   optional int32 intDefault = 2;
   optional fixed32 fix32 = 3;
   repeated string text = 4;
}

AutoProtoSchemaBuilder アノテーションに移行

import org.infinispan.protostream.annotations.ProtoField;
import org.infinispan.protostream.descriptors.Type;

public class SimpleEntry {

  private String description;
  private Collection<String> text;
  private int intDefault;
  private Integer fixed32;

  @ProtoField(number = 1)
  public String getDescription() {...}

  @ProtoField(number = 4, collectionImplementation = LinkedList.class)
  public Collection<String> getText() {...}

  @ProtoField(number = 2, defaultValue = "0")
  public int getIntDefault() {...}

  @ProtoField(number = 3, type = Type.FIXED32)
  public Integer getFixed32() {...}

  // public Getter, Setter, equals and HashCode methods and convenient constructors omitted for brevity
}

import org.infinispan.protostream.GeneratedSchema;
import org.infinispan.protostream.annotations.AutoProtoSchemaBuilder;

@AutoProtoSchemaBuilder(includeClasses = { SimpleEntry.class }, schemaFileName = "simple.proto", schemaFilePath = "proto", schemaPackageName = "example")
public interface SimpleEntryInitializer extends GeneratedSchema {
}

重要な所見

Exception ( ISPN004034: Unable to unmarshall bytes )

このセクションでは、ProtoStream がネイティブに処理しないフィールドを含む MessageMarshaller 実装の移行例を示します。

次の例では BigInteger クラスを使用していますが、データグリッドアダプターやカスタムクラスを含め、すべてのクラスに適用されます。

import java.math.BigInteger;

public class CustomTypeEntry {

  final String description;
  final BigInteger bigInt;

  // public Getter, Setter, equals and HashCode methods and convenient constructors omitted for brevity
}

import org.infinispan.protostream.MessageMarshaller;

public class CustomTypeEntryMarshaller implements MessageMarshaller<CustomTypeEntry> {

  @Override
  public void writeTo(ProtoStreamWriter writer, CustomTypeEntry testEntry) throws IOException {
    writer.writeString("description", testEntry.description);
    writer.writeString("bigInt", testEntry.bigInt.toString());
  }

  @Override
  public CustomTypeEntry readFrom(MessageMarshaller.ProtoStreamReader reader) throws IOException {
    final String desc = reader.readString("description");
    final BigInteger bInt = new BigInteger(reader.readString("bigInt"));

    return new CustomTypeEntry(desc, bInt);
  }
}

syntax = "proto2";

package example;

message CustomTypeEntry {
   required string description = 1;
   required string bigInt = 2;
}

アダプタークラスを使用して移行されたコード

ProtoAdapter アノテーションを使用して、MessageMarshaller 実装で作成した Protobuf スキーマと互換性のある Protobuf スキーマを生成する方法で CustomType クラスをマーシャリングできます。

このアプローチでは、次のことができます。

次の例が示す CustomTypeEntry クラスの ProtoStream アノテーションを含む CustomTypeEntryAdapter クラス:

import java.math.BigInteger;

import org.infinispan.protostream.annotations.ProtoAdapter;
import org.infinispan.protostream.annotations.ProtoFactory;
import org.infinispan.protostream.annotations.ProtoField;

@ProtoAdapter(CustomTypeEntry.class)
public class CustomTypeEntryAdapter {

  @ProtoFactory
  public CustomTypeEntry create(String description, String bigInt) {
    return new CustomTypeEntry(description, new BigInteger(bigInt));
  }

  @ProtoField(number = 1, required = true)
  public String getDescription(CustomTypeEntry t) {
    return t.description;
  }

  @ProtoField(number = 2, required = true)
  public String getBigInt(CustomTypeEntry t) {
    return t.bigInt.toString();
  }
}

次の例が示す CustomTypeEntryAdapter クラスを参照する AutoProtoSchemaBuilder アノテーションと t もに SerializationContextInitializer を示しています。

import org.infinispan.protostream.GeneratedSchema;
import org.infinispan.protostream.annotations.AutoProtoSchemaBuilder;

@AutoProtoSchemaBuilder(includeClasses = { CustomTypeEntryAdapter.class },
   schemaFileName = "custom.proto",
   schemaFilePath = "proto",
   schemaPackageName = "example")
public interface CustomTypeAdapterInitializer extends GeneratedSchema { }

アダプタークラスなしで移行されたコード

アダプタークラスを作成する代わりに、ProtoStream アノテーションを CustomTypeEntry クラスに直接追加できます。

次の例が示す直接 ProtoStream アノテーションを含む CustomTypeEntry クラス:

import java.math.BigInteger;

public class CustomTypeEntry {

  @ProtoField(number = 1)
  final String description;
  @ProtoField(number = 2)
  final BigInteger bigInt;

  @ProtoFactory
  public CustomTypeEntry(String description, BigInteger bigInt) {
    this.description = description;
    this.bigInt = bigInt;
  }

  // public Getter, Setter, equals and HashCode methods and convenient constructors omitted for brevity
}

以下の例は、CustomTypeEntry および BigIntegerAdapter クラスを参照する AutoProtoSchemaBuilder アノテーションと共に SerializationContextInitializer を示しています。

import org.infinispan.protostream.GeneratedSchema;
import org.infinispan.protostream.annotations.AutoProtoSchemaBuilder;
import org.infinispan.protostream.types.java.math.BigIntegerAdapter;

@AutoProtoSchemaBuilder(includeClasses = { CustomTypeEntry.class,
   BigIntegerAdapter.class },
   schemaFileName = "customtype.proto",
   schemaFilePath = "proto",
   schemaPackageName = "example")
public interface CustomTypeInitializer extends GeneratedSchema { }

前述の SerializationContextInitializer 実装から Protobuf スキーマを生成すると、以下の Protobuf スキーマになります。

syntax = "proto2";

package example;

message BigInteger {
   optional bytes bytes = 1;
}

message CustomTypeEntry {
   optional string description = 1;
   optional BigInteger bigInt = 2;
}

Data Grid 7.3 サービスは、/opt/datagrid/standalone/data にマウントされたストレージボリュームを使用します。

Data Grid 8 サービスは、/opt/infinispan/server/data にマウントされた永続ボリューム要求を使用します。

Data Grid 7.3 では、リモートシェルからのみ CLI にアクセスできます。Data Grid 7.3 CLI 経由で行った変更は Pod にバインドされ、再起動後は維持されませんでした。Data Grid 8 を使用すると、OpenShift でクラスターを使用して管理操作を実行したり、データを操作したりするための完全に機能するメカニズムとして CLI を使用できます。

Data Grid 7.3 は OpenShift のコンソールをサポートしませんでした。Data Grid 8 では、コンソールを使用して OpenShift で実行されているクラスターを監視し、管理操作を実行し、キャッシュをリモートで作成できます。

Data Grid 7.3 では、Source-to-Image(S2I) プロセスおよび ConfigMap API を使用して、OpenShift で実行される Data Grid サーバーイメージをカスタマイズできます。

Data Grid 8 では、Red Hat は、Red Hat Container Registry からの Data Grid イメージのカスタマイズをサポートしません。

Data Grid Operator は、OpenShift 上の Data Grid 8 クラスターのデプロイメントおよび管理を処理します。

その結果、カスタムを使用できません。

Data Grid 8.0 および 8.1 では、Data Grid Operator では JAR ファイルや他のアーティファクトなどのカスタムコードをデプロイすることはできません。Data Grid 8.2 では、永続ボリューム要求 (PVC) を使用して、カスタムコードを Data Grid クラスターで利用可能にすることができます。

Data Grid 7.3 で利用可能だったデプロイメント設定テンプレートおよび環境変数は、Data Grid 8 で削除されました。

ソースおよびターゲットのキャッシュストアを StoreMigrator プロパティーで設定します。

# Example configuration for migrating to a JDBC String-Based cache store
target.type=STRING
target.cache_name=myCache
target.dialect=POSTGRES
target.marshaller.class=org.example.CustomMarshaller
target.marshaller.externalizers=25:Externalizer1,org.example.Externalizer2
target.connection_pool.connection_url=jdbc:postgresql:postgres
target.connection_pool.driver_class=org.postrgesql.Driver
target.connection_pool.username=postgres
target.connection_pool.password=redhat
target.db.major_version=9
target.db.minor_version=5
target.db.disable_upsert=false
target.db.disable_indexing=false
target.table.string.table_name_prefix=tablePrefix
target.table.string.id.name=id_column
target.table.string.data.name=datum_column
target.table.string.timestamp.name=timestamp_column
target.table.string.id.type=VARCHAR
target.table.string.data.type=bytea
target.table.string.timestamp.type=BIGINT
target.key_to_string_mapper=org.infinispan.persistence.keymappers. DefaultTwoWayKey2StringMapper

# Example configuration for migrating from a RocksDB cache store.
source.type=ROCKSDB
source.cache_name=myCache
source.location=/path/to/rocksdb/database
source.compression=SNAPPY

# Example configuration for migrating to a Single File cache store.
target.type=SINGLE_FILE_STORE
target.cache_name=myCache
target.location=/path/to/sfs.dat

# Example configuration for migrating to a Soft-Index File cache store.
target.type=SOFT_INDEX_FILE_STORE
target.cache_name=myCache
target.location=path/to/sifs/database
target.location=path/to/sifs/index