[jira] [Updated] (APEXCORE-581) Delivery of Custom Control Tuples

2016-11-30 Thread David Yan (JIRA)

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

David Yan updated APEXCORE-581:
---
Description: 
The behavior should be as follow:

- The control tuples should only be sent to downstream at streaming window 
boundaries
- The control tuples should be sent to all partitions downstream
- The control tuples should be sent in the same order of arrival.
- Within a streaming window, do not send the same control tuple twice, even if 
the same control tuple is received multiple times within that window. This is 
possible if the operator has two input ports. (The LinkedHashMap should be 
easily able to ensure both order and uniqueness.)
- The delivery of control tuples needs to stop at DelayOperator. 
- When a streaming window is committed, remove the associated LinkedHashMap 
that belong to windows with IDs that are less than the committed window
- It's safe to assume the control tuples are rare enough and can fit in memory

This will involve an additional MessageType to represent a custom control 
tuple. 
We probably need to have a data structure (possibly a LinkedHashMap) per 
streaming window that stores the control tuple in the buffer server.


  was:

The behavior should be as follow:

- The control tuples should only be sent to downstream at streaming window 
boundaries
- The control tuples should be sent to all partitions downstream
- The control tuples should be sent in the same order of arrival.
- Within a streaming window, do not send the same control tuple twice, even if 
the same control tuple is received multiple times within that window. This is 
possible if the operator has two input ports. (The LinkedHashMap should be 
easily able to do ensure both order and uniqueness.)
- The delivery of control tuples needs to stop at DelayOperator. 
- When a streaming window is committed, remove the associated LinkedHashMap 
that belong to windows with IDs that are less than the committed window
- It's safe to assume the control tuples are rare enough and can fit in memory

This will involve an additional MessageType to represent a custom control 
tuple. 
We probably need to have a data structure (possibly a LinkedHashMap) per 
streaming window that stores the control tuple in the buffer server.



> Delivery of Custom Control Tuples
> -
>
> Key: APEXCORE-581
> URL: https://issues.apache.org/jira/browse/APEXCORE-581
> Project: Apache Apex Core
>  Issue Type: Sub-task
>Reporter: David Yan
>
> The behavior should be as follow:
> - The control tuples should only be sent to downstream at streaming window 
> boundaries
> - The control tuples should be sent to all partitions downstream
> - The control tuples should be sent in the same order of arrival.
> - Within a streaming window, do not send the same control tuple twice, even 
> if the same control tuple is received multiple times within that window. This 
> is possible if the operator has two input ports. (The LinkedHashMap should be 
> easily able to ensure both order and uniqueness.)
> - The delivery of control tuples needs to stop at DelayOperator. 
> - When a streaming window is committed, remove the associated LinkedHashMap 
> that belong to windows with IDs that are less than the committed window
> - It's safe to assume the control tuples are rare enough and can fit in memory
> This will involve an additional MessageType to represent a custom control 
> tuple. 
> We probably need to have a data structure (possibly a LinkedHashMap) per 
> streaming window that stores the control tuple in the buffer server.



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


[jira] [Updated] (APEXCORE-581) Delivery of Custom Control Tuples

2016-11-30 Thread David Yan (JIRA)

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

David Yan updated APEXCORE-581:
---
Description: 

The behavior should be as follow:

- The control tuples should only be sent to downstream at streaming window 
boundaries
- The control tuples should be sent to all partitions downstream
- The control tuples should be sent in the same order of arrival.
- Within a streaming window, do not send the same control tuple twice, even if 
the same control tuple is received multiple times within that window. This is 
possible if the operator has two input ports. (The LinkedHashMap should be 
easily able to do ensure both order and uniqueness.)
- The delivery of control tuples needs to stop at DelayOperator. 
- When a streaming window is committed, remove the associated LinkedHashMap 
that belong to windows with IDs that are less than the committed window
- It's safe to assume the control tuples are rare enough and can fit in memory

This will involve an additional MessageType to represent a custom control 
tuple. 
We probably need to have a data structure (possibly a LinkedHashMap) per 
streaming window that stores the control tuple in the buffer server.


  was:
This will involve an additional MessageType to represent a custom control 
tuple. 
We probably need to have a data structure (possibly a LinkedHashMap) per 
streaming window that stores the control tuple in the buffer server.

The behavior should be as follow:

- The control tuples should only be sent to downstream at streaming window 
boundaries
- The control tuples should be sent to all partitions downstream
- The control tuples should be sent in the same order of arrival.
- Within a streaming window, do not send the same control tuple twice, even if 
the same control tuple is received multiple times within that window. This is 
possible if the operator has two input ports. (The LinkedHashMap should be 
easily able to do ensure both order and uniqueness.)
- The delivery of control tuples needs to stop at DelayOperator. 
- When a streaming window is committed, remove the associated LinkedHashMap 
that belong to windows with IDs that are less than the committed window
- It's safe to assume the control tuples are rare enough and can fit in memory



> Delivery of Custom Control Tuples
> -
>
> Key: APEXCORE-581
> URL: https://issues.apache.org/jira/browse/APEXCORE-581
> Project: Apache Apex Core
>  Issue Type: Sub-task
>Reporter: David Yan
>
> The behavior should be as follow:
> - The control tuples should only be sent to downstream at streaming window 
> boundaries
> - The control tuples should be sent to all partitions downstream
> - The control tuples should be sent in the same order of arrival.
> - Within a streaming window, do not send the same control tuple twice, even 
> if the same control tuple is received multiple times within that window. This 
> is possible if the operator has two input ports. (The LinkedHashMap should be 
> easily able to do ensure both order and uniqueness.)
> - The delivery of control tuples needs to stop at DelayOperator. 
> - When a streaming window is committed, remove the associated LinkedHashMap 
> that belong to windows with IDs that are less than the committed window
> - It's safe to assume the control tuples are rare enough and can fit in memory
> This will involve an additional MessageType to represent a custom control 
> tuple. 
> We probably need to have a data structure (possibly a LinkedHashMap) per 
> streaming window that stores the control tuple in the buffer server.



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