Apache Geode отладка Неизвестный тип pdx = 2140705 - PullRequest
0 голосов
/ 03 июля 2018

Если я запускаю 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$1.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$9$1.run(DistributionManager.java:1108)
  at java.lang.Thread.run(Thread.java:748)

1 Ответ

0 голосов
/ 16 июля 2018

Вы можете определить непосредственную причину по трассировке стека.

Последовательный поток PDX содержит идентификатор типа, который является ссылкой на хранилище метаданных типа, поддерживаемых кластером GemFire. В этом случае сериализованные данные объекта содержали typeId, которого нет в хранилище метаданных кластера.

Таким образом, возникает вопрос: «что сериализовало этот объект и почему он использовал недопустимый идентификатор типа?»

Единственный способ, которым я видел это раньше, - это когда кластер полностью перезапускается и метаданные pdx удаляются, либо потому, что он не был постоянным, либо потому что был удален (например, путем очистки рабочего каталога локатора).

Клиенты GemFire ​​кэшируют отображение между типом и его идентификатором типа. Это позволяет им быстро сериализовать объекты без постоянного поиска идентификатора типа с сервера. Клиентские соединения могут сохраняться при перезапуске кластера. Когда клиент повторно подключается, он не сбрасывает кэшированную информацию и продолжает записывать объекты, используя свой идентификатор кэшированного типа.

Таким образом, сочетание перезапуска кластера с потерями метаданных pdx и не перезапущенного клиента (например, сервера приложений) - единственный способ, которым я видел это раньше. Это соответствует вашему сценарию?

Если это так, один из лучших способов избежать этого - сохранить ваши метаданные pdx и никогда не удалять их.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...