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

Yan Fang commented on SAMZA-437:
--------------------------------

Since we remove the lifecycle listener, do we need to add some docs about how 
people should do now ? when 
{quote}
Sometimes, you need to run your own code at specific points in a task's 
lifecycle. For example, you might want to set up some context in the container 
whenever a new message arrives, or perform some operations on startup or 
shutdown.
{quote}



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

Reply via email to