Re: Dealing with changing class definitions in Ignite

Denis, All First of all best wishes for the New Year. We understand the limitations concerning data that is stored in caches. But I feel it's quite limiting to apply these restrictions as well to runnables, it really makes dealing with changing code in runnables very annoying. And it prevents 2

Re: Dealing with changing class definitions in Ignite

Gert, All, That's not a peer-class-loading issue but rather the binary objects limitation. It's impossible to change the *type* of an object field. You can add new fields or remove existing ones. The same limitation applies to SQL - now way to change the type in runtime. That latter should be

Re: Dealing with changing class definitions in Ignite

For now we can work around the issue by overriding the BinaryNameMarshaller and ensuring our clients append a unique identifier behind the class name. This ensures that every client gets their own Binary Metadata records in the Marshaller for every class they serialize in the cluster.

Re: Dealing with changing class definitions in Ignite

Hello! I have found that you can avoid compute job type incompatibility problem (please see history below) by setting .setMarshaller(new OptimizedMarshaller()) in your Ignite configuration on all nodes. However, it is not clear at all why this is needed. Anybody can help? Why

Re: Dealing with changing class definitions in Ignite

Hey Ilya, I opened a ticket on the ignite Jira about it. https://issues.apache.org/jira/browse/IGNITE-10717 I attached a zip file containing a maven project with sample code that reproduces our issue. Reproducing the issue is rather easy though 1. Have a client + server, with peer class loading

Re: Dealing with changing class definitions in Ignite

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 : > Thanks for the

Re: Dealing with changing class definitions in Ignite

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

Re: Dealing with changing class definitions in Ignite

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,

Re: Dealing with changing class definitions in Ignite

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

Dealing with changing class definitions in Ignite

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