Hello! Can you show an example of "Ignite Runnables conflicting on the Binary Marshaller"? As a small code snippet perhaps?
Maybe I could recommend something but I lack understanding of your use case. Regards, -- Ilya Kasnacheev пн, 17 дек. 2018 г. в 18:12, Gert Dubois <[email protected]>: > Thanks for the reply. > > Everything related to the cache we understand the current architecture, in > our code base we'll probably treat everything cache related the same as > schema migrations in a DB (migration scripts, etc.). > Our real issue is with Ignite Runnables conflicting on the Binary > Marshaller. Every class that gets executed on Ignite as a job gets a stored > definition, this means we can't refactor classes that get used internally > by our Ignite Runnables, because doing so would prevent the updated code > from running. Even worse, if we update our libraries and they changed class > definitions we might run into the same issue, without changing a letter in > our own code. From the documentation it looked like Deployment Mode could > provide a solution for this issue but the Binary Marshaller seems to run > completely separate from the Deployment Mode. > > On Mon, Dec 17, 2018 at 3:18 PM Ilya Kasnacheev <[email protected]> > wrote: > >> Hello! >> >> As far as my understanding goes: >> You can't peer class load your Key/Value types. >> You also can't redeploy your Key/Value types. >> They even survive node restart via WORKDIR/marshaller directory, and come >> back to haunt you. >> >> There are plans to maybe ease some of those limitations in 3.0, but >> nothing concrete yet. It is not a bug rather a pillar of current Ignite >> architecture. You will have to route around it, such as introducing new >> fields instead of changing types. And maybe avoid having those types on >> server nodes at all, and relying on BinaryObject. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> пн, 17 дек. 2018 г. в 15:38, Gert Dubois <[email protected]>: >> >>> 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 >>>>>> >>>>>
