ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Dealing with changing class definitions in Ignite
Date Mon, 17 Dec 2018 14:18:16 GMT

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.

Ilya Kasnacheev

пн, 17 дек. 2018 г. в 15:38, Gert Dubois <gert.dubois@trendminer.com>:

> 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 <dmekhanikov@gmail.com>
> 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 <gert.dubois@trendminer.com>:
>>> 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>
>>> 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

View raw message