構成に関する詳細は、ここでは完全ではありません。これが発生する可能性のあるシナリオは多数あります。より可能性の高い状況の 1 つは、上記のコード スニペットがおそらくクライアント キャッシュであり、/HTTPAudit が何らかのピア サーバー リージョンへのプロキシ クライアント リージョンであるということです (データ ポリシーは不明ですが、これがクライアント/サーバー トポロジである場合はそれほど重要ではありません)。 )。
HTTPAudit は java.io.Serializable を実装しているため、GemFire は Java Serialization を使用してオブジェクトをネットワーク経由で送信します。
次に、GemFire はオブジェクトを取得した「フォーム」に格納します (この場合はシリアライズされます)。
次に、OQL ステートメント (Query) を実行し、オブジェクト (sessionId) のフィールドにアクセスします。GemFire は「Java Serialized」形式のデータにアクセスできないため、値を逆シリアル化してクエリの述語を検査する必要があります。
この場合、「GemFire Server」ノードには、必要な CLASSPATH に HTTPAudit クラスがないと推測されます。
上記のような OQL が発行されたときに GemFire サーバーで HTTPAudit オブジェクトの逆シリアル化を回避したい場合は、PDX シリアル化に切り替える必要があります ( http://gemfire.docs.pivotal.io/latest/userguide/developing /data_serialization/gemfire_pdx_serialization.html )、サーバーの構成の「read-serailized」属性を true に設定します。
ただし、PDX を使用している場合でも、オブジェクトに対するすべての OQL 操作が必ずしもオブジェクトをシリアライズされた形式に保つわけではないため、注意が必要です。
たとえば、次のような OQL クエリ...
SELECT audit.toString() FROM /HTTPAudit 監査 WHERE ...
PDX のシリアル化されたオブジェクトでさえ、クエリの実行中に逆シリアル化されます。
toString() の呼び出しは良い方法ではありませんが (要点を示すだけです)、特定のオブジェクト操作により、GemFire が値を逆シリアル化して、処理中に OQL ステートメントでオブジェクト操作を実行する可能性があります。したがって、クラスがサーバーの CLASSPATH にある必要があります。ので注意してください。
ただし、あなたの場合、オブジェクトを保存してアクセスするために、より標準的ではあるが効率の悪いJavaシリアライゼーションを使用しているため、問題が発生します。PDX シリアル化とは異なり、GemFire がシリアル化された形式でオブジェクトのデータにアクセスできるようにする「型メタデータ」はありません。最初に「逆シリアル化」する必要はありません。Java シリアライゼーションでは、GemFire はオブジェクトの情報にアクセスするためにオブジェクトをデシリアライズする必要があります。
お役に立てれば。