[
https://issues.apache.org/jira/browse/MINIFI-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15651761#comment-15651761
]
ASF GitHub Bot commented on MINIFI-36:
--------------------------------------
Github user brosander commented on a diff in the pull request:
https://github.com/apache/nifi-minifi/pull/51#discussion_r87256369
--- Diff:
minifi-bootstrap/src/main/java/org/apache/nifi/minifi/bootstrap/RunMiNiFi.java
---
@@ -143,11 +145,18 @@
private volatile Set<Future<?>> loggingFutures = new HashSet<>(2);
private volatile int gracefulShutdownSeconds;
- private Set<ConfigurationChangeNotifier> changeNotifiers;
private Set<PeriodicStatusReporter> periodicStatusReporters;
+ private ConfigurationChangeCoordinator changeCoordinator;
private MiNiFiConfigurationChangeListener changeListener;
+ private volatile ByteBuffer currentConfigFile;
+
+ @Override
+ public ByteBuffer getConfigFile() {
+ return currentConfigFile;
--- End diff --
Sounds good
> Create mechanism that supports pull semantics for configuration changes
> -----------------------------------------------------------------------
>
> Key: MINIFI-36
> URL: https://issues.apache.org/jira/browse/MINIFI-36
> Project: Apache NiFi MiNiFi
> Issue Type: Improvement
> Components: Processing Configuration
> Reporter: Aldrin Piri
> Assignee: Joseph Percivall
> Fix For: 0.1.0
>
>
> Much like the efforts of MINIFI-12, it would also be convenient for a
> configuration in which an instance could reach out to a defined endpoint to
> poll for changes and bring those into the associated bootstrap process to
> activate a change in processing.
> Considerations include the mechanism in which polling occurs and how this is
> exposed. A way of knowing if the flow is new, likely bound to the efforts of
> MINIFI-35. In one case, it is conceivable that an instance could reach out
> to a NiFi instance and its associated API to receive configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
