Отладка Apache Geode Неизвестный тип pdx = 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$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)

apache geode gemfire
person rupweb    schedule 03.07.2018    source источник
comment
Есть ли ошибки в логах локатора или сервера?   -  person Jens D    schedule 03.07.2018

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

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

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

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

person Randy May    schedule 16.07.2018
comment
Да, я думаю, это соответствует сценарию, когда клиенты запускались, останавливались, запускались, останавливались много раз, затем, возможно, сервер перезапускался, а клиенты - нет и т. д. Спасибо за анализ - person rupweb; 10.03.2020
comment
Я настроил постоянное хранилище pdx и все равно получаю ту же ошибку - person SUMIT; 14.07.2020
comment
Эта JIRA о нескольких пулах может быть связана - person rupweb; 22.07.2020