Hi Pavel,
Snap! I just created https://issues.apache.org/jira/browse/IGNITE-8590 Feel free to delete it. Thanks, Raymond *From:* Pavel Tupitsyn [mailto:ptupit...@apache.org] *Sent:* Thursday, May 24, 2018 7:13 AM *To:* user@ignite.apache.org *Subject:* Re: Binary type has different fields error Hi Raymond, Many thanks for posting the root cause! I've filed a bug to investigate this: https://issues.apache.org/jira/browse/IGNITE-8588 Pavel On Wed, May 23, 2018 at 2:37 PM, Ilya Kasnacheev <ilya.kasnach...@gmail.com> wrote: Hello Raymond! I'm glad that confusion have cleared itself! Still you could fill an issue to Apache Ignite JIRA <https://issues.apache.org/jira/>, see if there's a decision to support this case eventually. The main concern here is that this pattern may arise in some code outside of user's control, which will prevent his objects from serializing. Regards, -- Ilya Kasnacheev 2018-05-23 14:31 GMT+03:00 Raymond Wilson <raymond_wil...@trimble.com>: Hi Ilya, I got to the bottom of it today. It is an error on my part. The Ignite exception is correct, but wasn’t initially obvious why it was complaining. We had a pair of classes defined like this: public class A { public int bob; } public class B : A { public int bob; } This compiles, though with a warning that B.bob hides A.bob. Ignite serialization is seeing the two bob members and complains! The second copy of the member should not have been there, and removing it resolved the problem I have not tested to see if this would work (using the new keywork to reintroduce the field, assuming this was something you needed to do): public class B { public int new bob; } I’m not sure if the marshaller should be expected to deal with this situation, and I’m not sure if .Net serialization deals with it either. Thanks, Raymond. *From:* Ilya Kasnacheev [mailto:ilya.kasnach...@gmail.com] *Sent:* Wednesday, May 23, 2018 11:09 PM *To:* user@ignite.apache.org *Subject:* Re: Binary type has different fields error Hello Raymond! This is unusual. Do you have a minimal reproducer by chance? Care to share it on e.g. github? Regards, -- Ilya Kasnacheev 2018-05-22 4:50 GMT+03:00 Raymond Wilson <raymond_wil...@trimble.com>: Hi Ilya, I found the folder and removed it. The issue still persist in a different context, with the exception below being thrown. This suggests PeerClassLoading is enabled, though I have not configured it, and its default value is Disabled. 2018-05-22 13:40:50,523 [13] ERROR PlanViewTileRenderer. ExecutePipeline raised exception System.AggregateException: One or more errors occurred. ---> Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs [type=SubGridsRequestArgument, field1=Filters, field2=Filters, fieldId=-854547461] at Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper, Boolean forceTimestamp) at Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId, IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log) at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32 typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc) at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type, BinaryFullTypeDescriptor desc) at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type) at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj) at Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter writer, Object o) at Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1 obj, BinaryWriter writer) at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj) at Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1 obj, BinaryWriter writer) at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj) at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o) at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job, BinaryWriter writer) at Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.<ExecuteClosures0>b__1a(BinaryWriter writer) at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1 action, IBinaryStream stream, Marshaller marsh) at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type, Action`1 writeAction) at Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3 task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount, Action`1 writeAction) --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout) at VSS.TRex.GridFabric.Requests.SubGridRequestsProgressive`2.Execute() in C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\GridFabric\Requests\SubGridRequestsProgressive.cs:line 107 at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Pipelines\SubGridPipelineBase.cs:line 241 at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Rendering\PlanViewTileRenderer.cs:line 262 ---> (Inner Exception #0) Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs [type=SubGridsRequestArgument, field1=Filters, field2=Filters, fieldId=-854547461] at Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper, Boolean forceTimestamp) at Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId, IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log) at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32 typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc) at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type, BinaryFullTypeDescriptor desc) at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type) at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj) at Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter writer, Object o) at Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1 obj, BinaryWriter writer) at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj) at Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1 obj, BinaryWriter writer) at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj) at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o) at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job, BinaryWriter writer) at Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.<ExecuteClosures0>b__1a(BinaryWriter writer) at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1 action, IBinaryStream stream, Marshaller marsh) at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type, Action`1 writeAction) at Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3 task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount, Action`1 writeAction)<--- Thanks, Raymond. *From:* Ilya Kasnacheev [mailto:ilya.kasnach...@gmail.com] *Sent:* Thursday, May 17, 2018 12:51 AM *To:* user@ignite.apache.org *Subject:* Re: Binary type has different fields error Hello! Yes, they are stored under work/marshaller. Should empty this dir before restarting node. Regards, -- Ilya Kasnacheev 2018-05-16 10:22 GMT+03:00 Raymond Wilson <raymond_wil...@trimble.com>: Thanks Pavel. I guess I’m confused that the type in question is not persisted, it is ephemeral. Is Ignite persisting knowledge about these types behind the scenes? Raymond. *From:* Pavel Tupitsyn [mailto:ptupit...@apache.org] *Sent:* Wednesday, May 16, 2018 7:02 PM *To:* user@ignite.apache.org *Subject:* Re: Binary type has different fields error In general, Ignite is tolerant to changes within your types, adding fields, removing them. But field type change is a breaking change. You have to use a new field name. Other Ignite experts may give advice on how to update schema, I'm a bit out of the loop on this. Thanks, Pavel On Wed, May 16, 2018 at 7:06 AM, Raymond Wilson <raymond_wil...@trimble.com> wrote: I just changed a field in a class from a long to a Guid. The class in question is marked [Serializable] and is passed to Ignite compute functions as a part of an argument to the compute function and is not saved to the persistent store. When I run the modified code against an Ignite grid with a persistent data store I get the following error. Is this intentional? How should type evolution ephemeral constructs handed to compute functions in Ignite be handled? Exception: System.AggregateException: One or more errors occurred. ---> Apache.Ignite.Core.Binary.BinaryObjectException: Binary type has different field types [typeName=VSS.TRex.Filters.CellPassAttributeFilter, fieldName=ElevationRangeDesignID, fieldTypeName1=long, fieldTypeName2=UUID] ---> Apache.Ignite.Core.Common.JavaException: class org.apache.ignite.binary.BinaryObjectException: Binary type has different field types [typeName=VSS.TRex.Filters.CellPassAttributeFilter, fieldName=ElevationRangeDesignID, fieldTypeName1=long, fieldTypeName2=UUID] at org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:1033) at org.apache.ignite.internal.pro cessors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:444) at org.apache.ignite.internal.pro cessors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:186) at org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1303) at org.apache.ignite.internal.pro cessors.platform.PlatformContextImpl.processMetadata(PlatformContextImpl.java:336) at org.apache.ignite.internal.pro cessors.platform.binary.PlatformBinaryProcessor.processInStreamOutLong(PlatformBinaryProcessor.java:70) at org.apache.ignite.internal.pro cessors.platform.PlatformAbstractTarget.processInStreamOutLong(PlatformAbstractTarget.java:87) at org.apache.ignite.internal.pro cessors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67) at Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.ExceptionCheck() at Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.CallLongMethod(GlobalRef obj, IntPtr methodId, Int64* argsPtr) at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInStreamOutLong(GlobalRef target, Int32 opType, Int64 memPtr) at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutLong(Int32 type, Action`1 writeAction) --- End of inner exception stack trace --- Etc….. Thanks, Raymond.