[
https://issues.apache.org/jira/browse/MINIFI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16014405#comment-16014405
]
ASF GitHub Bot commented on MINIFI-37:
--------------------------------------
Github user apiri commented on a diff in the pull request:
https://github.com/apache/nifi-minifi-cpp/pull/98#discussion_r117001163
--- 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 --
Not sure we should allow the NoOp repo for flowfiles as that should be
maintaining the state of our processing. When we get content established in a
similar fashion, also feels like it might not be a fit but could potentially
see some cases where there might be some benefit.
> 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)
