[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Fix Version/s: (was: 2.7) > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 3.0 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Minor > Labels: iep-17 > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Affects Version/s: (was: 1.7) 3.0 > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 3.0 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Minor > Labels: iep-17 > Fix For: 2.7 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Priority: Minor (was: Critical) > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Minor > Labels: iep-17 > Fix For: 2.7 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5551: --- Fix Version/s: (was: 2.6) 2.7 > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Critical > Labels: iep-17 > Fix For: 2.7 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-5551: - Labels: iep-17 (was: ) > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Critical > Labels: iep-17 > Fix For: 2.6 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Fix Version/s: (was: 2.5) 2.6 > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Critical > Fix For: 2.6 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Fix Version/s: (was: 2.4) 2.5 > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Critical > Fix For: 2.5 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Fix Version/s: (was: 2.3) 2.4 > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Critical > Fix For: 2.4 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-5551: - Priority: Critical (was: Major) > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Priority: Critical > Fix For: 2.2 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-5551: - Description: 1) The deployment assignment is stored using a map [node ID -> number of assigned services]. However, this assignment is not very effective for cases when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in this case, we can avoid assignment recalculation at all. The assignment for this case may look like (eachNode=N). In this case, the assignment does not change and we can effectively skip it during the reassign loop. 2) We store zero assignment counters, which does not make sense at all - if there are no service deployments for a node, there should be no corresponding entry in the map at all. The size of assignments for (maxPerCluster > 0) configurations is O(number of nodes in the cluster), but it should be O(maxPerCluster). 3) If an assignment did not change, we should not commit the assignment transaction - this is redundant 4) Perhaps, it also makes sense to calculate several assignments at once and do a putAll commit instead of single puts - this should also decrease the assignment calculation latency was: 1) The deployment assignment is stored using a map [node ID -> number of assigned services]. However, this assignment is not very effective for cases when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in this case, we can avoid assignment recalculation at all. The assignment for this case may look like (eachNode=N). In this case, the assignment does not change and we can effectively skip it during the reassign loop. 2) We store zero assignment counters, which does not make sense at all - if there are no service deployments for a node, there should be no corresponding entry in the map at all. The size of assignments for (maxPerCluster > 0) configurations is O(number of nodes in the cluster), but it should be O(maxPerCluster). 3) If an assignment did not change, we should not commit the assignment transaction - this is redundant > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk > Fix For: 2.2 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v6.4.14#64029)
