You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Pavel Tupitsyn (JIRA)" <ji...@apache.org> on 2016/08/01 09:59:20 UTC

[jira] [Commented] (IGNITE-2703) .NET: Dynamically registered classes must use binary serialization if possible.

    [ https://issues.apache.org/jira/browse/IGNITE-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401785#comment-15401785 ] 

Pavel Tupitsyn commented on IGNITE-2703:
----------------------------------------

Looks like we can't have dynamic registration for a StoreFactory for the same reason as we enforce [Serializable] affinity function: it is needed during cache start, so we can't use marshaller cache at the moment.

We can either enforce [Serializable], or enforce "unregistered type" mechanics where we write the full type name after the header.

> .NET: Dynamically registered classes must use binary serialization if possible.
> -------------------------------------------------------------------------------
>
>                 Key: IGNITE-2703
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2703
>             Project: Ignite
>          Issue Type: Task
>          Components: platforms
>    Affects Versions: 1.5.0.final
>            Reporter: Vladimir Ozerov
>            Assignee: Pavel Tupitsyn
>            Priority: Critical
>              Labels: .net, roadmap
>             Fix For: 1.7
>
>
> At present we support dynamic class registration in .NET, but they are written using deafult .NET mechanism. This is counterintuitive for users and not consistent with Java, where such classes are written in binary form.
> Proposed implementation plan:
> 1) For each dynamically registered class we must understand whether it could be serialized through binary or not. If not - print a warning and fallback to .NET.
> 2) Before writing a class we must ensure that it's [typeId -> name] pair is known to the cluster. If not - write full class name instead of type ID. Java already do that.
> 3) Last, to support backward compatibility we must be able to fallback to current mode with help of some boolean flag.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)