ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Vinogradov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-708) Need to remove background partition exchange
Date Wed, 14 Oct 2015 07:59:05 GMT

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

Anton Vinogradov commented on IGNITE-708:
-----------------------------------------

Gianfranco,

I'm working on https://issues.apache.org/jira/browse/IGNITE-1093 and have a lot of changes
at GridCachePartitionExchangeManager and it seems to be a good idea to wait until my task
finished.

Each partition have state (GridDhtPartitionState). GridDhtLocalPartition have methods own,
rent and tryEvict where partition can change it's state.
Partitions owns at affinity nodes at rebalancing, rents at former affinity nodes when all
affinity nodes owns partition and evicts when partition rented. That's common cases.
Please check usages of these methods in case I missed something.



> Need to remove background partition exchange
> --------------------------------------------
>
>                 Key: IGNITE-708
>                 URL: https://issues.apache.org/jira/browse/IGNITE-708
>             Project: Ignite
>          Issue Type: Task
>    Affects Versions: ignite-1.4
>            Reporter: Yakov Zhdanov
>            Assignee: Gianfranco Murador
>            Priority: Blocker
>              Labels: datagrid
>             Fix For: 1.5, 1.6
>
>
> Now every node sends its partition map to cache coordinator (which is the oldest node
in topology) and coordinator spreads full partition map to every node in topology. This happens
for each cache separately. This seems to take place even if there were no changes to local
partition maps. Given we guarantee communication message delivery this background process
seems to be an overkill.
> Exchange should happen only if any changes took place.
> After dynamic cache start has been introduced, we can have significant amount of live
caches at some point of app lifecycle and app may suffer from  background exchange which is
obviously not a requirement (and may be never has been the one).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message