[ 
https://issues.apache.org/jira/browse/IGNITE-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Kalashnikov updated IGNITE-5795:
--------------------------------------
    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|https://github.com/apache/ignite/pull/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.

  was:
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|https://github.com/apache/ignite/pull/2330]

To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it 
will force registering key.


> Binary metadata is not registered during start of cache
> -------------------------------------------------------
>
>                 Key: IGNITE-5795
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5795
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>    Affects Versions: 2.0
>            Reporter: Dmitry Karachentsev
>            Assignee: Anton Kalashnikov
>            Priority: Major
>              Labels: usability
>             Fix For: 2.8
>
>
> 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|https://github.com/apache/ignite/pull/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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to