[jira] [Updated] (IGNITE-9275) [POC] Introduce mechanism to fetch partition file via a p2p protocol
[ https://issues.apache.org/jira/browse/IGNITE-9275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9275: -- Fix Version/s: (was: 2.9) > [POC] Introduce mechanism to fetch partition file via a p2p protocol > > > Key: IGNITE-9275 > URL: https://issues.apache.org/jira/browse/IGNITE-9275 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-28 > > As a first step to estimate how much faster the file-rebalancing may be, I > suggest to implement a simple partition fetch procedure via the communication > SPI extension: > 1) Node A sends a partition fetch request to node B > 2) Node B starts a checkpoint and creates a local copy of the partition. Note > that during the partition copy there might be concurrent ongoing checkpoints, > this must be handled properly > 3) Node B establishes a new TCP connection on the TCP communication port > (handshake and verification is assumed) > 4) Node B calls transferFile (or native analogue, investigation needed) to > send the partition file in the most effective way > 5) Node A writes the file to a specified location on the local file system > After this mechanics is implemented, we need to hack the rebalance code and > use partition fetch logic instead of regular rebalance to measure > 1) How much faster (or slower) the new approach performs > 2) How it affects the concurrent transactions in the grid -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9275) [POC] Introduce mechanism to fetch partition file via a p2p protocol
[ https://issues.apache.org/jira/browse/IGNITE-9275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9275: Fix Version/s: (was: 2.8) 2.9 > [POC] Introduce mechanism to fetch partition file via a p2p protocol > > > Key: IGNITE-9275 > URL: https://issues.apache.org/jira/browse/IGNITE-9275 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-28 > Fix For: 2.9 > > > As a first step to estimate how much faster the file-rebalancing may be, I > suggest to implement a simple partition fetch procedure via the communication > SPI extension: > 1) Node A sends a partition fetch request to node B > 2) Node B starts a checkpoint and creates a local copy of the partition. Note > that during the partition copy there might be concurrent ongoing checkpoints, > this must be handled properly > 3) Node B establishes a new TCP connection on the TCP communication port > (handshake and verification is assumed) > 4) Node B calls transferFile (or native analogue, investigation needed) to > send the partition file in the most effective way > 5) Node A writes the file to a specified location on the local file system > After this mechanics is implemented, we need to hack the rebalance code and > use partition fetch logic instead of regular rebalance to measure > 1) How much faster (or slower) the new approach performs > 2) How it affects the concurrent transactions in the grid -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9275) [POC] Introduce mechanism to fetch partition file via a p2p protocol
[ https://issues.apache.org/jira/browse/IGNITE-9275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9275: Summary: [POC] Introduce mechanism to fetch partition file via a p2p protocol (was: Introduce mechanism to fetch partition file via a p2p protocol) > [POC] Introduce mechanism to fetch partition file via a p2p protocol > > > Key: IGNITE-9275 > URL: https://issues.apache.org/jira/browse/IGNITE-9275 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Goncharuk >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-28 > Fix For: 2.8 > > > As a first step to estimate how much faster the file-rebalancing may be, I > suggest to implement a simple partition fetch procedure via the communication > SPI extension: > 1) Node A sends a partition fetch request to node B > 2) Node B starts a checkpoint and creates a local copy of the partition. Note > that during the partition copy there might be concurrent ongoing checkpoints, > this must be handled properly > 3) Node B establishes a new TCP connection on the TCP communication port > (handshake and verification is assumed) > 4) Node B calls transferFile (or native analogue, investigation needed) to > send the partition file in the most effective way > 5) Node A writes the file to a specified location on the local file system > After this mechanics is implemented, we need to hack the rebalance code and > use partition fetch logic instead of regular rebalance to measure > 1) How much faster (or slower) the new approach performs > 2) How it affects the concurrent transactions in the grid -- This message was sent by Atlassian JIRA (v7.6.14#76016)
