[
https://issues.apache.org/jira/browse/IGNITE-25322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Aouad updated IGNITE-25322:
----------------------------------
Description:
Ignite thin client has a seemingly incoherent behavior for determining the
serializer of a user defined type. On thin client startup, the passed binary
configuration, is taken into account when registering the type descriptors. For
each binary type configuration, the type is registered along with its specified
serializer, rather than the default serializer being chosen for it.
This is not what is happening, however, in the following case: A thin client is
connected to 2 servers. One of the servers crashes (chaos testing). The
reliable channel fail listener is invoked which cleans up registered type
descriptors. When a type that was initially configured in the binary config
along with its serializer is used, the type descriptor will be recreated,
passing through the method defaultSerializer, which only returns the default
serializer if defined, ignoring whether or not a specific config has been
specified for the class.
I patched ignite on my side to test a fix, and it works.
was:
Ignite thin client has a seemingly incoherent behavior for determining the
serializer of a user defined type. On thin client startup, the passed binary
configuration, is taken into account when registering the type descriptors. For
each binary type configuration, the type is registered along with its specified
serializer, rather than the default serializer being chosen for it.
This is not what is happening, however, in the following case: A thin client is
connected to 2 servers. One of the servers crashes (chaos testing). The
reliable channel fail listener is invoked which cleans up registered type
descriptors. When a type that was initially configured in the binary config
along with its serializer is used, the type descriptor will be recreated,
passing through the method defaultSerializer, which only returns the default
serializer if defined, ignoring whether or not a specific config has been
specified for the class.
I [patched
ignite|https://github.com/jeremyaouad/ignite/commit/8631642eb634c8fdd7bd142913a76c917ebfa6f1#diff-0b6b6de9d7cd36395bd30954afa10acb9ca3ebdca670c918d4c67a130c64eb22]
on my side to test a fix, and it works.
> defaultSerializer in BinaryContext should take into consideration the user
> passed binary config
> -----------------------------------------------------------------------------------------------
>
> Key: IGNITE-25322
> URL: https://issues.apache.org/jira/browse/IGNITE-25322
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 2.17
> Reporter: Jeremy Aouad
> Assignee: Jeremy Aouad
> Priority: Major
> Attachments:
> 0001-IGNITE-25322-defaultSerializer-in-BinaryContext-shou.patch
>
>
> Ignite thin client has a seemingly incoherent behavior for determining the
> serializer of a user defined type. On thin client startup, the passed binary
> configuration, is taken into account when registering the type descriptors.
> For each binary type configuration, the type is registered along with its
> specified serializer, rather than the default serializer being chosen for it.
> This is not what is happening, however, in the following case: A thin client
> is connected to 2 servers. One of the servers crashes (chaos testing). The
> reliable channel fail listener is invoked which cleans up registered type
> descriptors. When a type that was initially configured in the binary config
> along with its serializer is used, the type descriptor will be recreated,
> passing through the method defaultSerializer, which only returns the default
> serializer if defined, ignoring whether or not a specific config has been
> specified for the class.
> I patched ignite on my side to test a fix, and it works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
