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

ASF GitHub Bot commented on APEXCORE-10:
----------------------------------------

Github user ishark commented on a diff in the pull request:

    https://github.com/apache/incubator-apex-core/pull/250#discussion_r58954585
  
    --- Diff: 
engine/src/main/java/com/datatorrent/stram/plan/physical/PhysicalPlan.java ---
    @@ -357,25 +417,51 @@ public PhysicalPlan(LogicalPlan dag, PlanContext ctx) 
{
               if (!container.operators.isEmpty()) {
                 LOG.warn("Operator {} shares container without locality 
contraint due to insufficient resources.", oper);
               }
    +          // TODO: Check if PT Operators conflict in anti-affinity, Pick 
the first container that does not conflict
    --- End diff --
    
    This check cannot be done in logical Plan validation. Since, 2 operators 
could be assigned to same container even if there is not locality constraint. 
This may occur if maxContainer value is set less than the needed number of 
containers for operator.


> Enable non-affinity of operators per node (not containers)
> ----------------------------------------------------------
>
>                 Key: APEXCORE-10
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-10
>             Project: Apache Apex Core
>          Issue Type: Task
>            Reporter: Amol Kekre
>            Assignee: Isha Arkatkar
>              Labels: roadmap
>
> The issue happens on cloud which provides virtual cores with software like 
> Xen underneath. In effect if CPU intensive operators land up on same node we 
> have a resource bottleneck,
> Need to create an attribute that does the following
> - Operators A & B should not be on same node
> - Stram should use this attribute to try to get containers on different node
> It is understood that the user is making an explicit choice to use NIC 
> instead of stream local optimization



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

Reply via email to