The issue is still present in 2.7. I added a ticket on Jira with sample code that reproduces the issue.
https://issues.apache.org/jira/browse/IGNITE-10717 For now I think we can work around the issue by overriding the default BinaryNameMapper, but this feels rather hacky to me. On Mon, Dec 17, 2018 at 11:54 AM Denis Mekhanikov <[email protected]> wrote: > Gert, > > Could you check if the problem with a deployment mode reproduces on Ignite > 2.7? > If it does, please file a ticket with an explanation and a reproducer to > https://issues.apache.org/jira/ > > Thanks! > Denis > > > пн, 17 дек. 2018 г. в 12:12, Gert Dubois <[email protected]>: > >> 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 <[email protected]> >> wrote: >> >>> 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 >>> >>
