[
https://issues.apache.org/jira/browse/APEXCORE-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tushar Gosavi updated APEXCORE-621:
-----------------------------------
Description:
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.
was:
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 upstream
operator in case of threadlocal/container local case to avoid getting detected
as blocked early.
> 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
>
> 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)
