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

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_r87225923
  
    --- 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 --
    
    Can we make a defensive copy or provide an immutable value here?  I'm 
worried about multiple callers getting a stateful object.


> 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)

Reply via email to