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

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

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

    https://github.com/apache/nifi-minifi-cpp/pull/98#discussion_r117082313
  
    --- Diff: README.md ---
    @@ -299,7 +299,19 @@ Additionally, users can utilize the MiNiFi Toolkit 
Converter (version 0.0.1 - sc
     
         if you do not want to enable client certificate base authorization
         nifi.security.need.ClientAuth=false
    -
    +    
    +### Configuring Volatile and NO-OP Repositories
    +
    +     in minifi.properties 
    +     
    +     # For Volatile Repositories:
    +     nifi.flow.repository.class.name=VolatileRepository
    +     nifi.provenance.repository.class.name=VolatileRepository
    +     
    +     # For NO-OP Repositories:
    +    nifi.flow.repository.class.name=NoOpRepository
    --- End diff --
    
    My thought, initially was that we could have processors that could be self 
contained and work with or without connections. In those cases the 
configuration wouldn't need to be updated but we may be able to disable both 
repositories at runtime thus altering certain devices to have a different 
capability. I support what you are suggesting though but wonder if the Java 
model fits all embedded devices and use cases. 


> Native Volatile Content Repository implementation
> -------------------------------------------------
>
>                 Key: MINIFI-37
>                 URL: https://issues.apache.org/jira/browse/MINIFI-37
>             Project: Apache NiFi MiNiFi
>          Issue Type: Task
>          Components: C++, Core Framework
>            Reporter: Aldrin Piri
>            Assignee: marco polo
>            Priority: Minor
>              Labels: native
>
> Given the constrained environments in which MiNiFi could operate, it would be 
> beneficial to provide a content repository that is strictly in memory for 
> those environments where disk storage may be limited or non-existent. 
> This implementation should consider configuration options around its 
> footprint such as number of entries held and/or sheer capacity.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to