[
https://issues.apache.org/jira/browse/NIP-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18017098#comment-18017098
]
Pierre Villard commented on NIP-10:
-----------------------------------
Good points Joe.
We always limit the number of bulletins returned for a given component (process
group, processors, etc) but if we imagine a very large flow that is not broken
down into process groups and if we imagine that all processors are returning
bulletins we would indeed increase by a lot the payload returned by the API to
serve the UI (and the replication that goes with it). I do think that the user
would be in a very bad spot even now if such a scenario happens :) but yeah,
that's why we could make it smart in the Bulletin DTO factory to only have the
stacktrace for the API that serves the bulletin board and remove this
information for any other API.
Regarding the type of users and where that could be useful, I also agree with
you. This is why I think it's good to scope it to only the bulletin board view
(which is probably not a place users go to very often today) and, on the UI
side, we could imagine something where the display would not change much
compared to now but would provide the option to expand the bulletin if there is
a stack trace.
> Add stackTrace to Bulletin
> --------------------------
>
> Key: NIP-10
> URL: https://issues.apache.org/jira/browse/NIP-10
> Project: NiFi Improvement Proposal
> Issue Type: Improvement
> Reporter: Pierre Villard
> Priority: Major
>
> As a NiFi user, it is not always easy to quickly access the logs. Bulletins
> are a good way to surface potential errors when data is being processed in
> the flow but in case this requires deeper debugging, the information
> currently provided in a bulletin is not always enough.
> In such a case the NiFi user may not have permissions or easy access to the
> logs of the NiFi instance and would need to get in touch with a NiFi admin
> able to retrieve the underlying log message for the bulletin and provide the
> full stack trace. This can make the overall troubleshooting process longer.
> It could be useful to add a stackTrace String to the Bulletin object in
> nifi-api and provide the option to expand a bulletin in the Bulletin Board
> view in order to see and easy copy in the clipboard the potential stack trace
> associated to the bulletin.
> We want to use a String instead of a Throwable to make sure we do not have
> serialisation issues across the NiFi nodes but we want to make we retain the
> proper format of the stacktrace for proper rendering in the UI.
> Additionally, it may be good to evaluate if we should specifically remove the
> value of this new field when being called via APIs that are not for the
> bulletin board. This may not be necessary though as we never retrieve a large
> number of bulletins anyway.
> Expected changes:
> * The API change would be to add a stackTrace String field to the Bulletin
> object in nifi-api
> * In the implementations of LogObserver, convert the throwable into the
> string representing the stack trace and add it to the bulletin
> * In the UI, improve the bulletin board to properly render the stack trace
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
