[ 
https://issues.apache.org/jira/browse/NIFI-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396958#comment-16396958
 ] 

ASF GitHub Bot commented on NIFI-4849:
--------------------------------------

Github user mcgilman commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/2468#discussion_r174137385
  
    --- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/StandardProcessorNode.java
 ---
    @@ -1349,10 +1404,12 @@ private void initiateStart(final 
ScheduledExecutorService taskScheduler, final l
                             LOG.debug("Successfully invoked @OnScheduled 
methods of {} but scheduled state is no longer STARTING so will stop processor 
now", processor);
     
                             // can only happen if stopProcessor was called 
before service was transitioned to RUNNING state
    +                        activateThread();
                             try {
                                 
ReflectionUtils.quietlyInvokeMethodsWithAnnotation(OnUnscheduled.class, 
processor, processContext);
    -                        } finally {
    --- End diff --
    
    Not sure which approach is correct, but this appears to be a change in 
behavior. If OnUnscheduled throws, OnStopped will not be invoked anymore. Do we 
want this new behavior, or do this finally block contain a nested try/finally 
with deactiveThread() in the nested finally? This would maintain the same 
behavior.


> Add REST Endpoint for gathering Processor Diagnostics information
> -----------------------------------------------------------------
>
>                 Key: NIFI-4849
>                 URL: https://issues.apache.org/jira/browse/NIFI-4849
>             Project: Apache NiFi
>          Issue Type: Sub-task
>          Components: Core Framework
>            Reporter: Mark Payne
>            Assignee: Mark Payne
>            Priority: Major
>             Fix For: 1.6.0
>
>
> We need to add a REST endpoint that will use the appropriate resources to 
> gather the Processor Diagnostics information. Information to return should 
> include things like:
>  * Processor config
>  * Processor status
>  * Garbage Collection info
>  * Repo Sizes
>  * Connection info for connections whose source or destination is the 
> processor
>  * Controller Services that the processor is referencing



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to