[
https://issues.apache.org/jira/browse/BEAM-6725?focusedWorklogId=205500&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-205500
]
ASF GitHub Bot logged work on BEAM-6725:
----------------------------------------
Author: ASF GitHub Bot
Created on: 27/Feb/19 23:58
Start Date: 27/Feb/19 23:58
Worklog Time Spent: 10m
Work Description: ibzib commented on pull request #7941: [BEAM-6725]
share some Flink job invocation code with Samza runner
URL: https://github.com/apache/beam/pull/7941#discussion_r260997541
##########
File path:
runners/samza/src/main/java/org/apache/beam/runners/samza/SamzaJobInvocation.java
##########
@@ -71,58 +48,17 @@ private SamzaPipelineResult invokeSamzaJob() {
}
}
- @Override
- public void start() {
Review comment:
The whole point of this PR is I thought it might be useful to share much of
`FlinkJobInvocation`'s logic with other runners. With these changes, Samza
runner should be doing the exact same things as before, except inside a future.
Is there some reason that wouldn't be desirable?
----------------------------------------------------------------
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: 205500)
Time Spent: 2h 20m (was: 2h 10m)
> Move runner-agnostic code out of FlinkJobInvocation
> ---------------------------------------------------
>
> Key: BEAM-6725
> URL: https://issues.apache.org/jira/browse/BEAM-6725
> Project: Beam
> Issue Type: Task
> Components: runner-flink, runner-samza, runner-spark
> Reporter: Kyle Weaver
> Assignee: Kyle Weaver
> Priority: Major
> Labels: portability
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Like BEAM-6714, FlinkJobInvocation contains some code (for asynchronously
> running jobs) that isn't really Flink specific and therefore could/should be
> reused by other portable runners. I'm thinking instead of an interface,
> JobInvocation should be made an abstract class that implements the methods
> that it currently abstracts, with an abstract method `runPipeline` for the
> runner-specific details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
