[
https://issues.apache.org/jira/browse/SAMZA-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201368#comment-14201368
]
Chris Riccomini commented on SAMZA-364:
---------------------------------------
Relates to SAMZA-437, where we removed lifecycle listeners.
> Refactor lifecycle listener APIs
> --------------------------------
>
> Key: SAMZA-364
> URL: https://issues.apache.org/jira/browse/SAMZA-364
> Project: Samza
> Issue Type: Bug
> Components: container
> Affects Versions: 0.8.0
> Reporter: Chris Riccomini
>
> There are a many cases where a developer might like to plug into different
> points throughout the lifecycle of a Samza job's execution. Example use cases
> for this include:
> * Wanting to initialize setup/tear down of a slf4j log binding (SAMZA-350)
> * Wanting to initialize remote systems that the job interacts with.
> * Wanting to setup a custom HTTP (or some other) server for operational
> purposes.
> Potential injection points include:
> # SamzaContainer startup/shutdown.
> # Before/after processing a message in a TaskInstance.
> # Before/after init'ing a TaskInstance.
> # Before/after shutting down a TaskInstance.
> # Before/after windowing a TaskInstance.
> # Before/after committing offsets.
> # Before/after a job is started.
> # All of the YARN AM related events.
> Right now, we have a TaskLifecycleListener. This is insufficient to cover all
> cases, and is somewhat cumbersome to deal with because we instantiate one
> listener per TaskInstance in a container.
> We should refactor and re-design the lifecycle APIs for Samza. This will
> include investigating how other servlets/containers handle things, writing a
> doc, and implementing the new API.
> I expect that this will result in backwards incompatible changes with
> TaskLifecycleListener. I think this is OK.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
