Hello, Denis. It’s a known issue for me. Metastore is a private API, isn’t it? AFAICU it can occur for two reasons:
* User migrates from custom Ignite fork that has private improvements or plugins that write to the metastore. * We have a blocker bug and just remove some internal class that can be written into metastore from distribution. I planned to fix it with some system flag. During startup administrator just sets a list of the metastore items that should be ignored. Please, take a look at the PR [1] WDYT? > it’s better to limit the metastorage with storing primitives only I think that ability to write object is very useful and should stay. [1] https://github.com/apache/ignite/pull/8221 > 18 дек. 2020 г., в 12:06, Mekhanikov Denis <dmekhani...@gmail.com> написал(а): > > Hi everyone! > > Ignite has a limitation that it can’t work with custom classes put into > metastorage: https://issues.apache.org/jira/browse/IGNITE-13642 > If you put a POJO into the metastorage, then Ignite will try to deserialize > it using the classes it finds on the classpath. If it can’t do the > deserialization, then the node will fail. > > There is an opinion that the metastorage wasn’t design for a case when > classes that can disappear from Ignite distribution. > If we follow this path, then it’s better to limit the metastorage with > storing primitives only, so that it’s impossible to occasionally put anything > breaking. > If a piece of configuration is put into the metastorage by a plugin, then the > plugin will be in charge of deserializing the configuration, and not Ignite. > > Alternatively we can try to fix the metastorage and make it ignore > deserialization errors when they occur. > > What do you think? > > Denis
