[
https://issues.apache.org/jira/browse/SAMZA-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866556#comment-15866556
]
Navina Ramesh commented on SAMZA-1084:
--------------------------------------
I had a discussion with [~boryas] and [~nickpan47] offline. The consensus is
that if we go with Option #2 above, the user model still looks weird because
the user thread will be blocked. What does that mean for the application itself
is not clean. Ultimately, the user will end up invoking the blocking call in a
separate thread and continuously poll for status or poll in background. This is
really no different than the threading model we have today.
For now, we will continue with the existing asynchronous api for start, with
the option of blocking until start. Instead of providing a set of lifecycle
handlers, it seems sufficient to only provide an error handler callback. This
callback will be invoked in the context of the StreamProcessor thread and will
only be invoked on fatal/irrecoverable errors from the StreamProcessor.
> User thread does not see errors from the processor thread when using the
> StreamProcessor API
> --------------------------------------------------------------------------------------------
>
> Key: SAMZA-1084
> URL: https://issues.apache.org/jira/browse/SAMZA-1084
> Project: Samza
> Issue Type: Bug
> Reporter: Navina Ramesh
> Assignee: Navina Ramesh
> Fix For: 0.13.0
>
>
> The current user model for StreamProcessor API allows the user to start
> (asynchronous) and stop processor. awaitStart allows the user to wait until
> the processor actually initializes and starts processing messages. There are
> certain limitations to this API:
> 1. In case the processor fails during processing or prior to processing, the
> error is not propagated to the user context. It is very hard to troubleshoot
> and take action on error/shutdown.
> 2. There is also no way for the user to check the status of the processor.
> 3. (More of implementation detail than an API issue) Another issue is that we
> are using an Executor to run the container in a separate thread. The
> container uses another Executor to run the tasks. We need to understand the
> performance impact of using 2 levels of Executors in a single StreamProcessor
> instance.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
