Hi All,
Currently we can shutdown an Apex app in the following ways:
1. Throw ShutdownException() from *all* the input operators
2. Use Apex CLI to shutdown an app using the YARN App Id
I think we should have some way of shutting down an application from within
an operator. It is not always true
I think this would be a great addition for batch use cases or use
cases were DAG needs to be shutdown after detecting some
completion/error condition through the operator. We have one Jira
Opened for such functionality
https://issues.apache.org/jira/browse/APEXCORE-503.
- Tushar.
On Wed, Jan 18,
+1 for the feature in general.
Though I have a question about it: Lets say 10th operator in the DAG
initiates the shutdown.. And operator being in quite downstream as compared
to Input Operator, it might be fairly behind in window it is processing.
What happens to the data being already processed
This JIRA is to stop the DAG in a crude manner, based on an error
condition. I think this might also need similar functionality as an error
condition can occur anywhere in the DAG.
Perhaps we can modify the same JIRA to include a graceful + ungraceful
(kill) shutdown from any operator in the DAG.
I have similar question/concerns. When a downstream operator initiates a
shutdown, how is that trigger signaled to and co-ordinated with the input
operators stopping their input reading activity? Or idempotency etc don’t
matter after shutdown?
On 1/17/17, 10:31 PM, "Chinmay Kolhatkar" wrote:
If it is not an error condition, I would like for the data that is already
sent out by the upstream operators to get processed, before the shutdown of
an operator is initiated. Imagine something like a control tuple that
starts from the input operators and flows down the stream and stops the
contai
+1 to idea.
Will this ensure downstream operators to process all data received before
shutdown is called?
Also, how do we plan to handle cases where 2 sub-DAGs merge to a single
operator somewhere downstream, and an operator in one of the sub-DAGs sends
ShutdownException.
Ajay
On Wed, Jan 18, 2
Hi Sanjay,
The task of the shutdown is to stop the processing from the input operator
itself. Once we reach a consistent state (endWindow() for example), we stop
the input operator. Thereafter, the next operators in the DAG would only
have to process the data which is already emitted by the input o
Yes Ajay, for a graceful shutdown, the data sent out should be processed.
On Wed, Jan 18, 2017 at 12:19 PM, AJAY GUPTA wrote:
> +1 to idea.
>
> Will this ensure downstream operators to process all data received before
> shutdown is called?
> Also, how do we plan to handle cases where 2 sub-DAGs
Can be done by sending "shutdown" message via heartbeat to Stram. Then on
stram can shutdown the entire app
Thks
Amol
On Tue, Jan 17, 2017 at 11:05 PM, Bhupesh Chawda
wrote:
> Yes Ajay, for a graceful shutdown, the data sent out should be processed.
>
> On Wed, Jan 18, 2017 at 12:19 PM, AJAY G
Yes, Amol. That will be the case for a kill type of shutdown.
But for graceful shutdown, it is important that each operator in the DAG
processes exactly the same amount of data. That is the reason the shutdown
needs to start at input operators and stop their functioning as the first
step. Thereafte
Agreed on input adapter way.
Enforcing all input adapters send shutdown on the same window cannot be
guaranteed, so there will be a corner case where windows are not aligned.
An ask from Stram to send shutdown way in the future reduces the scope of
the corner case, but then defeats the purpose. Ev
Bhupesh,
If your intention is to let processing complete, the sources should
terminate the stream (that's already implemented, except that you want to
initiate it from another operator). It does not really matter if they all
stop at the same streaming window.
If you want to just stop the applicat
Hi Thomas,
The part of initiating the shutdown from another operator was the original
intention of the email.
~ Bhupesh
On Wed, Jan 18, 2017 at 10:35 PM, Thomas Weise wrote:
> Bhupesh,
>
> If your intention is to let processing complete, the sources should
> terminate the stream (that's already
Hi Thomas,
Handling application shutdown from an operator with help of stats
listener can be lot of work, instead we could provide an shortcut api
for
user to terminate the application. It could be based on response code
from statsListener as well as throwing an special exception from
operator thr
15 matches
Mail list logo
