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.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:444)

                at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:186)

                at
org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1303)

                at
org.apache.ignite.internal.processors.platform.PlatformContextImpl.processMetadata(PlatformContextImpl.java:336)

                at
org.apache.ignite.internal.processors.platform.binary.PlatformBinaryProcessor.processInStreamOutLong(PlatformBinaryProcessor.java:70)

                at
org.apache.ignite.internal.processors.platform.PlatformAbstractTarget.processInStreamOutLong(PlatformAbstractTarget.java:87)

                at
org.apache.ignite.internal.processors.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.

Reply via email to