Вы можете определить непосредственную причину по трассировке стека.
Последовательный поток PDX содержит идентификатор типа, который является ссылкой на хранилище метаданных типа, поддерживаемых кластером GemFire. В этом случае сериализованные данные объекта содержали typeId, которого нет в хранилище метаданных кластера.
Таким образом, возникает вопрос: «что сериализовало этот объект и почему он использовал недопустимый идентификатор типа?»
Единственный способ, которым я видел это раньше, - это когда кластер полностью перезапускается и метаданные pdx удаляются, либо потому, что он не был постоянным, либо потому что был удален (например, путем очистки рабочего каталога локатора).
Клиенты GemFire кэшируют отображение между типом и его идентификатором типа. Это позволяет им быстро сериализовать объекты без постоянного поиска идентификатора типа с сервера. Клиентские соединения могут сохраняться при перезапуске кластера. Когда клиент повторно подключается, он не сбрасывает кэшированную информацию и продолжает записывать объекты, используя свой идентификатор кэшированного типа.
Таким образом, сочетание перезапуска кластера с потерями метаданных pdx и не перезапущенного клиента (например, сервера приложений) - единственный способ, которым я видел это раньше. Это соответствует вашему сценарию?
Если это так, один из лучших способов избежать этого - сохранить ваши метаданные pdx и никогда не удалять их.