Apache Geode 调试未知 pdx 类型=2140705
Apache Geode debug Unknown pdx type=2140705
如果我启动 GFSH 客户端并连接到 Geode。 myRegion
中有很多数据,要检查它然后我 运行:
query --query="select * from /myRegion"
我收到回复:
Result : false
startCount : 0
endCount : 20
Message : Unknown pdx type=2140705
如何解决/调试这个问题?
更新:Geode 服务器日志中的错误是:
[info 2018/07/04 10:53:07.275 BST IsGeode <Function Execution Processor1> tid=0x48] Exception occurred:
java.lang.IllegalStateException: Unknown pdx type=1318971
at org.apache.geode.internal.InternalDataSerializer.readPdxSerializable(InternalDataSerializer.java:3042)
at org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2859)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
at org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:90)
at org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1911)
at org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1904)
at org.apache.geode.internal.cache.PreferBytesCachedDeserializable.getDeserializedValue(PreferBytesCachedDeserializable.java:73)
at org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1269)
at org.apache.geode.internal.cache.LocalRegion$NonTXEntry.getValue(LocalRegion.java:8771)
at org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:179)
at org.apache.geode.internal.cache.EntriesSet$EntriesIterator.next(EntriesSet.java:134)
at org.apache.geode.cache.query.internal.CompiledSelect.doNestedIterations(CompiledSelect.java:837)
at org.apache.geode.cache.query.internal.CompiledSelect.doIterationEvaluate(CompiledSelect.java:699)
at org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:423)
at org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:53)
at org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:558)
at org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:385)
at org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:319)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.select(DataCommandFunction.java:247)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.select(DataCommandFunction.java:202)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.execute(DataCommandFunction.java:147)
at org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:185)
at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
at org.apache.geode.distributed.internal.DistributionMessage.run(DistributionMessage.java:440)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:662)
at org.apache.geode.distributed.internal.DistributionManager.run(DistributionManager.java:1108)
at java.lang.Thread.run(Thread.java:748)
您可以从堆栈跟踪中找出直接原因。
PDX 序列化流包含一个类型 ID,它是对由 GemFire 集群维护的类型元数据存储库的引用。在这种情况下,对象的序列化数据包含一个不在集群元数据存储库中的 typeId。
所以问题就变成了,"what serialized that object and why did it use an invalid type id ?"
我以前见过这种情况发生的唯一方法是当集群完全重启并且 pdx 元数据消失时,要么是因为它不是持久的,要么是因为它被删除了(例如通过清除定位器工作目录) ).
GemFire 客户端缓存类型与其类型 ID 之间的映射。这使他们能够快速序列化对象,而无需不断地从服务器查找类型 ID。客户端连接可以在集群重启后持续存在。当客户端重新连接时,它不会刷新缓存的信息并继续使用其缓存的类型 ID 写入对象。
所以 pdx 元数据丢失集群重启和客户端未重启(例如应用程序服务器)的组合是我以前见过这种情况的唯一方式。这符合您的情况吗?
如果是这样,避免这种情况的最佳方法之一是保留您的 pdx 元数据并且永远不要删除它。
如果我启动 GFSH 客户端并连接到 Geode。 myRegion
中有很多数据,要检查它然后我 运行:
query --query="select * from /myRegion"
我收到回复:
Result : false
startCount : 0
endCount : 20
Message : Unknown pdx type=2140705
如何解决/调试这个问题?
更新:Geode 服务器日志中的错误是:
[info 2018/07/04 10:53:07.275 BST IsGeode <Function Execution Processor1> tid=0x48] Exception occurred:
java.lang.IllegalStateException: Unknown pdx type=1318971
at org.apache.geode.internal.InternalDataSerializer.readPdxSerializable(InternalDataSerializer.java:3042)
at org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2859)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
at org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:90)
at org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1911)
at org.apache.geode.internal.cache.EntryEventImpl.deserialize(EntryEventImpl.java:1904)
at org.apache.geode.internal.cache.PreferBytesCachedDeserializable.getDeserializedValue(PreferBytesCachedDeserializable.java:73)
at org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1269)
at org.apache.geode.internal.cache.LocalRegion$NonTXEntry.getValue(LocalRegion.java:8771)
at org.apache.geode.internal.cache.EntriesSet$EntriesIterator.moveNext(EntriesSet.java:179)
at org.apache.geode.internal.cache.EntriesSet$EntriesIterator.next(EntriesSet.java:134)
at org.apache.geode.cache.query.internal.CompiledSelect.doNestedIterations(CompiledSelect.java:837)
at org.apache.geode.cache.query.internal.CompiledSelect.doIterationEvaluate(CompiledSelect.java:699)
at org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:423)
at org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:53)
at org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:558)
at org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:385)
at org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:319)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.select(DataCommandFunction.java:247)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.select(DataCommandFunction.java:202)
at org.apache.geode.management.internal.cli.functions.DataCommandFunction.execute(DataCommandFunction.java:147)
at org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:185)
at org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
at org.apache.geode.distributed.internal.DistributionMessage.run(DistributionMessage.java:440)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:662)
at org.apache.geode.distributed.internal.DistributionManager.run(DistributionManager.java:1108)
at java.lang.Thread.run(Thread.java:748)
您可以从堆栈跟踪中找出直接原因。
PDX 序列化流包含一个类型 ID,它是对由 GemFire 集群维护的类型元数据存储库的引用。在这种情况下,对象的序列化数据包含一个不在集群元数据存储库中的 typeId。
所以问题就变成了,"what serialized that object and why did it use an invalid type id ?"
我以前见过这种情况发生的唯一方法是当集群完全重启并且 pdx 元数据消失时,要么是因为它不是持久的,要么是因为它被删除了(例如通过清除定位器工作目录) ).
GemFire 客户端缓存类型与其类型 ID 之间的映射。这使他们能够快速序列化对象,而无需不断地从服务器查找类型 ID。客户端连接可以在集群重启后持续存在。当客户端重新连接时,它不会刷新缓存的信息并继续使用其缓存的类型 ID 写入对象。
所以 pdx 元数据丢失集群重启和客户端未重启(例如应用程序服务器)的组合是我以前见过这种情况的唯一方式。这符合您的情况吗?
如果是这样,避免这种情况的最佳方法之一是保留您的 pdx 元数据并且永远不要删除它。