Hello! I guess this information was stored somewhere and is causing conflicts now. You can try dropping binary_meta/ directory from ignite work dir on all nodes, hope that it would be repopulated all right. Make sure to back it up first!
Regards, -- Ilya Kasnacheev чт, 25 февр. 2021 г. в 21:21, Mitchell Rathbun (BLOOMBERG/ 731 LEX) < [email protected]>: > We have recently been seeing the following error: > > SEVERE: Failed to serialize object > [typeName=com.bloomberg.aim.wingman.cachemgr.Ts3DataCache$Ts3CalcrtKey] > class org.apache.ignite.binary.BinaryObjectException: Failed to write > field [name=calcrtType] > at > org.apache.ignite.internal.binary.BinaryFieldAccessor.write(BinaryFieldAccessor.java:164) > at > org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:822) > at > org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232) > at > org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165) > at > org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152) > at > org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:248) > at > org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:548) > at > org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:1403) > at > org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:1198) > at > org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:751) > at > com.bloomberg.aim.wingman.cachemgr.Ts3DataCache.lambda$null$29(Ts3DataCache.java:1457) > at java.base/java.lang.Iterable.forEach(Iterable.java:75) > at > com.bloomberg.aim.wingman.cachemgr.Ts3DataCache.lambda$updateMetadataAsyncHelper$30(Ts3DataCache.java:1456) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: class org.apache.ignite.binary.BinaryObjectException: > Conflicting enum values. Name 'INT' uses ordinal value (2) that is also > used for name 'INTEGER' > [typeName='com.bloomberg.aim.wingman.common.dto.RealCalcrtFieldType'] > at > org.apache.ignite.internal.binary.BinaryUtils.mergeEnumValues(BinaryUtils.java:2501) > at > org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:1028) > at > org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport.requestMetadataUpdate(BinaryMetadataTransport.java:211) > at > org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:603) > at > org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:285) > at > org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:764) > at > org.apache.ignite.internal.binary.BinaryContext.registerDescriptor(BinaryContext.java:723) > at > org.apache.ignite.internal.binary.BinaryContext.registerClass(BinaryContext.java:581) > at > org.apache.ignite.internal.binary.BinaryContext.registerClass(BinaryContext.java:556) > at > org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteEnum(BinaryWriterExImpl.java:829) > at > org.apache.ignite.internal.binary.BinaryWriterExImpl.writeEnumField(BinaryWriterExImpl.java:1323) > at > org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write0(BinaryFieldAccessor.java:670) > at > org.apache.ignite.internal.binary.BinaryFieldAccessor.write(BinaryFieldAccessor.java:157) > ... 16 more > > > As part of the key in one of our classes, we have an enum, for which one > of the values is INT. It used to be INTEGER, but that was like 5 months > ago. Looking in this cache, there are multiple entries with INT being used, > and none with INTEGER. So why are we still getting this error? Writes with > INT have clearly worked in the past, and INTEGER is not in the cache and > hasn't been used in a long time. We recently updated from 2.7.5 to 2.9.1 as > well, not sure if that is related. > >
