[
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)
