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

ASF GitHub Bot commented on MINIFI-36:
--------------------------------------

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

    https://github.com/apache/nifi-minifi/pull/51#discussion_r87254681
  
    --- 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 --
    
    Here is the docs for ByteBuffer's "asReadyOnlyBuffer". The position is 
independent for each but share the same content (and prevent modification to 
the content). 
    
    One thing to note, the "currentConfigFile" won't ever be updated by writing 
to it (reference is updated when a new config is transformed). So we can make 
the underlying "currentConfigFile" read only too (effectively making it 
immutable).
    
    
https://docs.oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html#asReadOnlyBuffer--


> 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