Type not persistable: "class java.lang.Thread" for customized class loader and Postgresql storage target about store HOT 3 OPEN

The PersistenceExceptionTypeNotPersistable is caused by an unpersistable type. In your case it’s java.lang.Thread. This Exception is thrown at runtime the first time you try to persist such a type and later during the storage startup phase.

To identify the problematic type that references a non-persistable type have a look into the type- dictionary, the PersistenceTypeDictionary.ptd file in the storage directory. It is a human readable text.

To repair a storage that does no more start just delete the affected type-description from the type dictionary file.

from store.

Hi @hg-ms,
thank you for your response.
Unfortunately, there is no type-dictionary: the error occur during the initial start() phase of the Postgresql storage target together with those classloader customization. There are not even the both database tables storage$channel_0 and/or
storage in my Postgresql schema. If I switch to the other / default variant

EmbeddedStorageManager storageManager = EmbeddedStorage.start(fileSystem.ensureDirectoryPath("storage"));

both database tables are created, the table storagecontains an identifier PersistenceTypeDictionary.ptdbut without any Thread in the binary content. But in this case, the error is different: Without any store operation happened, after the next application start, the error TypeId inconsistency for RootData: typeDictionary type definition typeId = 1000072, validated type handler typeId = 1000076 occure, which seems to be related to the classloader issue. Therefor I use those classloader customization afterwards. Maybe this is not the correct way to handle this TypeId inconsistency error ?

from store.

As I am not able to reproduce the error I can give some tips only:
The TypeId inconsistency indicates that the type dictionary does not match the registered type handler. This may happen if you already started a storage with different type handlers configurated using the same Postgresql storage target.
In that case I’d recommend to delete the related Postgresql DB if possible.

An cause might be the SprinBoot Dev tools that may have caused the type differences. You can try to disable them.

An important thing to know is that starting an empty storage (no explicit Root set) cause writes. At least the default type dictionary and an empty internal root element is stored.

from store.