[
https://issues.apache.org/jira/browse/IGNITE-29110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-29110:
-------------------------------------
Attachment: reproducer.patch
> Restore predefined binary types missing on nodes without a platform processor
> and in the thin client
> ----------------------------------------------------------------------------------------------------
>
> Key: IGNITE-29110
> URL: https://issues.apache.org/jira/browse/IGNITE-29110
> Project: Ignite
> Issue Type: Bug
> Reporter: Nikita Amelchev
> Priority: Major
> Attachments: reproducer.patch
>
>
> IGNITE-26061 (2.18.0) moved the registration of several predefined binary
> types from the BinaryContext constructor into processors, so a BinaryContext
> created outside of them no longer knows these types.
> AffinityKey is registered only in CacheObjectBinaryProcessorImpl, so the
> BinaryContext created by the Java thin client does not have it. The class is
> listed as a system type, so the client marshals AffinityKey with the
> optimized marshaller instead of writing a binary object: partition awareness
> for such keys does not work even with an explicit CacheKeyConfiguration, the
> server has to deserialize and re-marshal every key, and
> IgniteClient.binary().toBinary() returns the object itself.
> PlatformDotNetSessionData, PlatformDotNetSessionLockResult and
> PlatformJavaObjectFactoryProxy are registered only in PlatformProcessorImpl,
> so a Java node started without PlatformConfiguration does not have them. A
> session value written by a .NET node cannot be read on such a node: cache.get
> and the server-side session entry processors fail with
> BinaryInvalidTypeException "Failed to resolve class name", which breaks
> ASP.NET session state in clusters of Java servers and .NET clients.
> The thin client module cannot reference these classes directly, so the
> registration needs a mechanism shared by nodes and clients.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
