You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Raymond Wilson <ra...@trimble.com> on 2018/05/16 04:06:02 UTC
Binary type has different fields error
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.
Re: Binary type has different fields error
Posted by Pavel Tupitsyn <pt...@apache.org>.
Deleted the second one.
On Wed, May 23, 2018 at 11:06 PM, Raymond Wilson <raymond_wilson@trimble.com
> wrote:
> 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:ptupitsyn@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.kasnacheev@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 <ra...@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.kasnacheev@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 <ra...@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.kasnacheev@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 <ra...@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:ptupitsyn@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_wilson@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.
>
>
>
>
>
>
>
>
>
>
>
RE: Binary type has different fields error
Posted by Raymond Wilson <ra...@trimble.com>.
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:ptupitsyn@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 <il...@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 <ra...@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.kasnacheev@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 <ra...@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.kasnacheev@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 <ra...@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:ptupitsyn@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 <ra...@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.
Re: Binary type has different fields error
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <il...@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 <ra...@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.kasnacheev@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 <ra...@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.Wri
>> teWithPeerDeployment(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__DisplayClas
>> s1d`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.netstanda
>> rd\GridFabric\Requests\SubGridRequestsProgressive.cs:line 107
>>
>> at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in
>> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstanda
>> rd\Pipelines\SubGridPipelineBase.cs:line 241
>>
>> at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in
>> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstanda
>> rd\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.Wri
>> teWithPeerDeployment(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__DisplayClas
>> s1d`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.kasnacheev@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 <ra...@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:ptupitsyn@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_wilson@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.bin
>> ary.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.bin
>> ary.BinaryContext.updateMetadata(BinaryContext.java:1303)
>>
>> at org.apache.ignite.internal.pro
>> cessors.platform.PlatformContextImpl.processMetadata(Platfor
>> mContextImpl.java:336)
>>
>> at org.apache.ignite.internal.pro
>> cessors.platform.binary.PlatformBinaryProcessor.processInStr
>> eamOutLong(PlatformBinaryProcessor.java:70)
>>
>> at org.apache.ignite.internal.pro
>> cessors.platform.PlatformAbstractTarget.processInStreamOutLo
>> ng(PlatformAbstractTarget.java:87)
>>
>> at org.apache.ignite.internal.pro
>> cessors.platform.PlatformTargetProxyImpl.inStreamOutLong(Pla
>> tformTargetProxyImpl.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.
>>
>>
>>
>>
>>
>>
>>
>
>
Re: Binary type has different fields error
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <ra...@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.kasnacheev@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 <ra...@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.kasnacheev@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 <ra...@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:ptupitsyn@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_wilson@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.
>
>
>
>
>
>
>
RE: Binary type has different fields error
Posted by Raymond Wilson <ra...@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.kasnacheev@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 <ra...@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.kasnacheev@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 <ra...@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:ptupitsyn@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 <ra...@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.
Re: Binary type has different fields error
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <ra...@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.kasnacheev@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 <ra...@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:ptupitsyn@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_wilson@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.
>
>
>
>
>
RE: Binary type has different fields error
Posted by Raymond Wilson <ra...@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.kasnacheev@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 <ra...@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:ptupitsyn@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 <ra...@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.
Re: Binary type has different fields error
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <ra...@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:ptupitsyn@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_wilson@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.
>
>
>
RE: Binary type has different fields error
Posted by Raymond Wilson <ra...@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:ptupitsyn@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 <ra...@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.
Re: Binary type has different fields error
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <ra...@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.
>