[
https://issues.apache.org/jira/browse/SAMZA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Riccomini updated SAMZA-437:
----------------------------------
Attachment: SAMZA-437-1.patch
Attaching rebased patch. Also, added docs, per-[~closeuris]'s request.
> Remove TaskLifecycleListener
> ----------------------------
>
> Key: SAMZA-437
> URL: https://issues.apache.org/jira/browse/SAMZA-437
> Project: Samza
> Issue Type: Bug
> Components: container
> Reporter: Chris Riccomini
> Attachments: SAMZA-437-0.patch, SAMZA-437-1.patch
>
>
> 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)
