ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Dubois <gert.dub...@trendminer.com>
Subject Re: Dealing with changing class definitions in Ignite
Date Mon, 17 Dec 2018 09:11:56 GMT
I investigated the issue further and narrowed the issue down to the Binary
Marshaller not working as expected given the configured Deployment Mode.
When forcing my clients to use unique class names in the metadata of the
Binary Marshaller (I forced this by overriding the global BinaryNameMapper
and appending a per-client unique suffix to every class name) the
Deployment Mode behaves as expected. I assume the Binary Marshaller keeps a
cluster wide state of the Metadata of classes and it merges it whenever we
serialize a class on a node (regardless of the configured Deployment Mode).
Why is the behaviour of the Binary Marshaller not consistent with the way
the Deployment Mode works? Is there a cleaner way to solve this, besides
overriding the BinaryNameMapper?

On Fri, Dec 14, 2018 at 1:07 PM Gert Dubois <gert.dubois@trendminer.com>

> Hi,
> On my current project we are confronted with an issue we are struggling to
> figure out.
> We have a simple topology where we have a client node running an
> IgniteRunnable to a server node. Both nodes have peerClassLoading=true and
> the default binaryConfiguration with compactFooters=false. The client is
> started with clientMode=true
> After execution we shut the client down and refactor the field type of one
> of the fields in our IgniteRunnable. When we now restart the client we get
> the following exception:
> Caused by: org.apache.ignite.binary.BinaryObjectException: Binary type has
> different field types [typeName=com.trendminer.compute.ClientJob,
> fieldName=param2, fieldTypeName1=double, fieldTypeName2=int]
> We tried different Deployment modes, ISOLATED, SHARED/CONTINUOUS with
> different userVersion. But nothing we change enables us to execute the new
> class definition on the server node.
> Ignite Version is 2.4.0
> Since we are using persistence in our production environment and this
> causes class definitions for the binary marshaller to be remembered even
> after cluster restart this is blocking for us since this either forces us
> to manually clear out the binary data and restart our cluster or it
> prevents us from refactoring code we we send into Ignite, which is not
> always possible.
> So we would like to know what the intended way is to deal with changing
> class definitions of tasks sent into Ignite?
> Regards,
> Gert

View raw message