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 >> >
