[
https://issues.apache.org/jira/browse/BEAM-5791?focusedWorklogId=157799&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-157799
]
ASF GitHub Bot logged work on BEAM-5791:
----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Oct/18 20:31
Start Date: 23/Oct/18 20:31
Worklog Time Spent: 10m
Work Description: kennknowles commented on a change in pull request
#6752: [BEAM-5791] Implement time-based pushback in the dataflow harness data
plane.
URL: https://github.com/apache/beam/pull/6752#discussion_r227552645
##########
File path:
sdks/java/fn-execution/src/main/java/org/apache/beam/sdk/fn/data/CloseableFnDataReceiver.java
##########
@@ -24,6 +24,8 @@
* <p>The close method for a {@link CloseableFnDataReceiver} must be
idempotent.
*/
public interface CloseableFnDataReceiver<T> extends FnDataReceiver<T>,
AutoCloseable {
+ void flush() throws Exception;
Review comment:
Ah it is javadoc complaint.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 157799)
Time Spent: 2h 10m (was: 2h)
> Bound the amount of data on the data plane by time.
> ---------------------------------------------------
>
> Key: BEAM-5791
> URL: https://issues.apache.org/jira/browse/BEAM-5791
> Project: Beam
> Issue Type: Improvement
> Components: runner-dataflow, sdk-java-harness, sdk-py-harness
> Reporter: Robert Bradshaw
> Assignee: Henning Rohde
> Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> This is especially important for Fn API reads, where each element represents
> a shard to read and may be very expensive, but many elements may be waiting
> in the Fn API buffer.
> The need for this will be mitigated with full SDF support for liquid sharding
> over the Fn API, but not eliminated unless the runner can "unread" elements
> it has already sent.
> This is especially important in for dataflow jobs that start out small but
> then detect that they need more workers (e.g. due to the initial inputs being
> an SDF).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
