ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Dubois <gert.dub...@trendminer.com>
Subject Re: Dealing with changing class definitions in Ignite
Date Mon, 17 Dec 2018 12:37:44 GMT
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
>>>
>>

Mime
View raw message