You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@samza.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/05/03 22:11:04 UTC
[jira] [Commented] (SAMZA-1212) Refactor interaction between
StreamProcessor, JobCoordinator and SamzaContainer
[ https://issues.apache.org/jira/browse/SAMZA-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995780#comment-15995780 ]
ASF GitHub Bot commented on SAMZA-1212:
---------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/samza/pull/148
> Refactor interaction between StreamProcessor, JobCoordinator and SamzaContainer
> -------------------------------------------------------------------------------
>
> Key: SAMZA-1212
> URL: https://issues.apache.org/jira/browse/SAMZA-1212
> Project: Samza
> Issue Type: Bug
> Reporter: Navina Ramesh
> Assignee: Navina Ramesh
> Fix For: 0.13.0
>
>
> Currently, StreamProcessor is a dummy wrapper for JobCoordinator and the JobCoordinator directly controls the lifecycle of SamzaContainer. This has a couple of drawbacks:
> 1. Each implementation of JobCoordinator needs to manage the container lifecycle. This seems redundant as the lifecycle of SamzaContainer is driven by availability of JobModel and updates to it.
> 2. The StreamProcessor interface requirements kind of bleed into JobCoordinator interface. For example, StreamProcessor interacts with user-api. If the requirements for the user-api change , it will directly impact the JobCoordinator interface as well. A good example of such a design creep is the "awaitStop" interface. While this is a reasonable requirement from the user's perspective of a StreamProcessor, it should not impose the same requirement on every implementation of JobCoordinator.
> 3. Error handling is pretty straight-forward when there is a control hierarchy of components. However, some implementations of JobCoordinators are synchronous, while others are Asynchronous. This will directly impact how errors/exceptions are propagated across the stack. It will be much cleaner if the StreamProcessor can handle the errors/exception from both container and coordinator.
> These are the primary motivations for refactoring.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)