[jira] [Commented] (SAMZA-437) Remove TaskLifecycleListener

["Chris Riccomini (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SAMZA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185917#comment-14185917 ] 

Chris Riccomini commented on SAMZA-437:
---------------------------------------

I pretty much agree with everything you've said. I just don't think TaskLifecycleListener is a good API. A wrapper around StreamTasks (or other wrappers) provides much better capabilities. This begs the question whether the task wrapper paradigm should be part of the framework or not. The argument for including it in the framework would be to allow the type of ecosystem that you describe. My argument against it would be for simplicity's sake to not include it. If we do see this pattern being common, then we could integrate the concept later. As it is, I've seen only one implementation of TaskLifecycleListener, and it has been replaced by the wrapper-style now.

> Remove TaskLifecycleListener
> ----------------------------
>
>                 Key: SAMZA-437
>                 URL: https://issues.apache.org/jira/browse/SAMZA-437
>             Project: Samza
>          Issue Type: Bug
>          Components: container
>            Reporter: Chris Riccomini
>
> We recently had a use case where we needed to wrap the Samza process() method in some code. The TaskLifecycleListener was insufficient to do this. We get a beforeProcess and afterProcess, but what we really wanted was:
> {code}
> def wrapProcess(...) {
>   foo.doSomething(new Wrapper() {
>     task.process(...)
>   })
> }
> {code}
> We ended up just writing a wrapper task, and having the normal code defined via a subtask config:
> {noformat}
> task.class=foo.bar.WrapperTask
> task.subtask.class=foo.bar.NormalTask
> {noformat}
> Both of these tasks implement StreamTask. Samza just sees WrapperTask, and treats it like a normal task. Wrapper task instantiates the subtask, and manages its lifecycle internally.
> This approach seems superior to the TaskLifecycleListener.
> * Allows tasks to be composed multiple times.
> * Removes this complexity from the Samza framework, and makes it a concern of the job owner.
> * Allows the wrapper task to do things like filtering messages, tweaking configs and serialization, catching exceptions, etc.
> Given this, it seems that TaskLifecycleListener is a degenerate case, and adds complexity to the framework. I propose removing it.



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