An exception thrown in your script and not caught will cause the process
session to roll back, meaning that the flowfile will be go back to the
input queue and retry. If you have the processor set to run on schedule
every 0 seconds, it might retry a lot :). You are correct that routing to
REL_FAILURE is usually better than retrying, but I suppose it depends on
the particular flow.
ExecuteScript provides a local script variable, 'log', which you can use to
log messages to the regular NiFi log. The messages get sent to the same
log files, following the rules outlined in conf/logback.xml, and will show
up in the UI as bulletins if the severity deserves it. So you can do
log.error("Something bad happpened")
And it will both log and display as you would expect a processor error to
display. It is an instance of ComponentLog, so there are also debug(),
info(), warn(), etc.
James
On Wed, Aug 2, 2017 at 12:22 PM, wildo <willy.de...@moserit.com> wrote:
> James- thanks for the comment. I've been hacking on this all day and think
> I
> have the python written to do what I need. I have just one follow up
> question as I'm new to the ExecuteScript processor.
>
>
> -What do I do on exception? Some of the cookbook example scripts seem to
> print to traceback:
>
> except:
> traceback.print_exec(file=sys.stdout)
> raise
>
>
> ...but I'm curious what you should do in a production environment. Instead
> of raising the exception, should you instead transfer the session to
> REL_FAILURE? Or maybe raising the exception automatically transfers to
> REL_FAILURE?
>
> Also- I'm guessing that in the real world you'd probably write that
> exception to some logger, rather than stdout correct?
>
>
>
>
>
> --
> View this message in context: http://apache-nifi-developer-l
> ist.39713.n7.nabble.com/Dynamic-attributes-on-repeating-
> capture-groups-tp16540p16565.html
> Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>
