[jira] [Comment Edited] (IGNITE-5795) Binary metadata is not registered during start of cache

["Alexandr Shapkin (Jira)" <ji...@apache.org>]

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

Alexandr Shapkin edited comment on IGNITE-5795 at 6/17/20, 10:34 PM:
---------------------------------------------------------------------

[~akalashnikov] the fix doesn't work for other platforms like .NET, C++ and all thin clients except Java. 

That's because other platforms don't have the Java classes and they do operate on their own abstraction and the following check will not work as a meta registration:

 
{code:java}
private void registerBinaryMetadata(CacheConfiguration ccfg, QuerySchema schema) throws BinaryObjectException {
...
Class<?> keyCls = U.box(U.classForName(qryEntity.findKeyType(), null, true));
Class<?> valCls = U.box(U.classForName(qryEntity.findValueType(), null,
It seems that in practice we do have all required information and a binaryt
{code}
The platforms may not operate Java objects directly and it seems redundant building a meta on a Java side one more time, keeping in mind that we actually do have the required binaryMeta proper to cache startup (at least for the .NET thick node)

 

I've created a separate ticket - https://issues.apache.org/jira/browse/IGNITE-13160 with an explanation of a problem from .NET side


was (Author: ashapkin):
[~akalashnikov] the fix doesn't work for other platforms like .NET, C++ and all thin clients except Java. 

That's because other platforms don't have the Java classes and they do operate on their own abstraction and the following check will not work as a meta registration:

 
{code:java}
private void registerBinaryMetadata(CacheConfiguration ccfg, QuerySchema schema) throws BinaryObjectException {
...
Class<?> keyCls = U.box(U.classForName(qryEntity.findKeyType(), null, true));
Class<?> valCls = U.box(U.classForName(qryEntity.findValueType(), null,
It seems that in practice we do have all required information and a binaryt
{code}
The platforms may not operate Java objects directly and it seems redundant building a meta on a Java side one more time, keeping in mind that we actually do have the required binaryMeta proper to cache startup (at least for the .NET thick node)

> 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: binary, sql
>    Affects Versions: 2.0
>            Reporter: Dmitry Karachentsev
>            Assignee: Anton Kalashnikov
>            Priority: Major
>              Labels: usability
>             Fix For: 2.8
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)