[
https://issues.apache.org/jira/browse/MINIFICPP-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16173694#comment-16173694
]
ASF GitHub Bot commented on MINIFICPP-36:
-----------------------------------------
Github user phrocker commented on the issue:
https://github.com/apache/nifi-minifi-cpp/pull/134
@achristianson It slipped my mind but was hoping to get ideas on what to do
when we have an invalid c2 configuration. C2 is a local element too, so at some
point we'll have scripts that leverage this capability to perform local
operations, so I imagine we'll always have C2 running ( which was the plan )
but the in the event that a protocol isn't properly configured i.e. no URL we
should disable that protocol entirely. thoughts?
Disabling the command and control element entirely seems antithetical to
command and control especially since we want local capabilities, but not trying
the protocol if it didn't fully initialize is advantageous and something I
completely forgot. Thoughts on that?
> Begin building controlling API to facilitate control of agents
> --------------------------------------------------------------
>
> Key: MINIFICPP-36
> URL: https://issues.apache.org/jira/browse/MINIFICPP-36
> Project: NiFi MiNiFi C++
> Issue Type: New Feature
> Reporter: marco polo
> Assignee: marco polo
> Priority: Critical
> Labels: Durability, Reliability, Statistics
>
> Begin building the controlling API in MiNiFi C++. This API will evolve and
> likely have public and private elements. As development progresses we may
> want more capabilities.
> What I want to create as a straw man will be basic control and metrics
> gathering
> -- Start
> -- Stop
> -- Pause
> -- Gather metrics
> ** Throughput of of flow components
> ** Execution time ( run time minus sleep time )
> ** Memory consumption
> -- Drain repositories
> -- Switch repository types.
> Better employ update listener within this controlling API
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
