Description
When cache configured with QueryEntity and used key type with @AffinityKeyMapped field, it will be ignored and wrong partition calculated. This happens because QueryEntity processing precedes key type registering in binary meta cache. On that step CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve type, so null returned and null putted in affKeyFields.
On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField will return null from affKeyFields, but should be affinity key field.
Test that reproduces problem in PR 2330
To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it will force registering key.
Root cause of this behaviour is that in during cache registration registration of metadata doesn't happen. It lead to exchange messages like (MappingProposedMessage, MetadataRequestMessage etc.) which are often redundant and also lead to behaviour described above(unhandled AffinityKeyMapped).
Main idea to fix this problem it is registration of metadata locally in during cache start on each node without messages exchange.
Attachments
Issue Links
- blocks
-
IGNITE-8006 Starting multiple caches slows down exchange process on joining node
- Resolved
- causes
-
IGNITE-14683 Binary type registration fails when class present in different packages with simple name mapper
- Open
-
IGNITE-9962 Unhandled exception during BatchCacheChangeRequest
- Resolved
-
IGNITE-13160 .NET: wrong affinity key registration with AffinityKeyMapped attribute
- Resolved
- is duplicated by
-
IGNITE-9964 SQL: query by affinity key fails when a table is created from a custom template
- Resolved
- is related to
-
IGNITE-5505 @AffinityKeyMapped annotation is ignored if class names are configured on BinaryConfiguration
- Resolved
- relates to
-
IGNITE-9964 SQL: query by affinity key fails when a table is created from a custom template
- Resolved
- links to