You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apex.apache.org by "Deepak Narkhede (JIRA)" <ji...@apache.org> on 2017/01/25 06:35:26 UTC

[jira] [Assigned] (APEXCORE-621) populate TIMEOUT_WINDOW_COUNT for thread local operators from downstreams.

     [ https://issues.apache.org/jira/browse/APEXCORE-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Deepak Narkhede reassigned APEXCORE-621:
----------------------------------------

    Assignee: Deepak Narkhede

> populate TIMEOUT_WINDOW_COUNT for thread local operators from downstreams.
> --------------------------------------------------------------------------
>
>                 Key: APEXCORE-621
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-621
>             Project: Apache Apex Core
>          Issue Type: Improvement
>            Reporter: Tushar Gosavi
>            Assignee: Deepak Narkhede
>
> A -> B -> C -> D
> In above dag if we have set TIMEOUT_WINDOW_COUNT on 'C' and 'B' and 'C' are in thread local, then 'B' uses default TIMEOUT_WINDOW_COUNT attribute and marked as blocked opeator while C is performing a time cosuming operation. The problem is more visible when operator B is partitioned and unifiers are deployed thread local to C, in this case unifiers are declared are blocked, and users need to remember to set TIMEOUT_WINDOW_COUNT on unifiers. 
> Instead platform could inherit TIMEOUT_WINDOW_COUNT attribute from downstream operator in case of threadlocal/container local case to avoid getting detected as blocked early.



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