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

ASF GitHub Bot commented on IGNITE-7699:
----------------------------------------

GitHub user sergey-chugunov-1985 opened a pull request:

    https://github.com/apache/ignite/pull/3523

    IGNITE-7699 ObjectBinaryProcessor improvements

    discovery protocol should not be triggered if requested metadata is the 
same as already existing; logging improvements

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/gridgain/apache-ignite ignite-7699

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/ignite/pull/3523.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #3523
    
----

----


> BinaryMetadata exchange should not be triggered if metadata was not updated
> ---------------------------------------------------------------------------
>
>                 Key: IGNITE-7699
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7699
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Sergey Chugunov
>            Assignee: Sergey Chugunov
>            Priority: Major
>             Fix For: 2.5
>
>
> It was found that DiscoveryCustomEvent-based implementation of BinaryMetadata 
> exchange protocol triggers propose-accept process even when it is not needed.
> In some situations BinaryObjects may be built with exactly the same scheme 
> many times, and registering of BinaryMetatada only once is enough.
> However current implementation executes expensive propose-accept process for 
> each *addMeta* request even if requesting meta is the same.
> Implementation should be improved so that prop-ack process is executed only 
> if BinaryMetadata really changed.



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

Reply via email to