[
https://issues.apache.org/jira/browse/NIFI-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14374957#comment-14374957
]
Joseph Gresock edited comment on NIFI-190 at 3/22/15 2:34 PM:
--------------------------------------------------------------
Thinking about this again, I'm wondering if the Wait and Notify processors can
be implemented using the existing DistributedMapCacheClient instead of writing
a WaitAndNotifyControllerService. The only behavior that isn't captured is the
ability to loop over the keys in the Map Cache. Therefore, the expiration time
of "signals" could be stored in the Notify processor in its own local Map in
addition to the actual ReleaseAttributes stored in the distributed cache.
Thoughts?
was (Author: jgresock):
Thinking about this again, I'm wondering if the Wait and Notify processors can
be implemented using the existing DistributedMapCacheClient instead of writing
a WaitAndNotifyControllerService. The only behavior that isn't captured is the
ability to loop over the keys in the Map Cache. Therefore, the expiration time
of "signals" could be stored in the Notify processor in its own local Map.
Thoughts?
> HoldFile processor
> ------------------
>
> Key: NIFI-190
> URL: https://issues.apache.org/jira/browse/NIFI-190
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
> Reporter: Joseph Gresock
> Priority: Minor
> Attachments: HoldFile_example.xml
>
>
> Our team has developed a processor for the following use case:
> * Format A needs to be sent to Endpoint A
> * Format B needs to be sent to Endpoint B, but should not proceed until A has
> reached Endpoint A. We most commonly have this restriction when Endpoint B
> requires some output of Endpoint A.
> The proposed HoldFile processor takes 2 types of flow files as input:
> * Files to be held
> * Signal files that can release corresponding held files, based on the value
> of a configurable "release" attribute
> Signal files are distinguished from held files by the presence of the
> "flow.file.release.value" attribute. The processor is configured with a
> "Release Signal Attribute". Held files with this attribute whose value
> matches a received signal value will be released.
> An example:
> HoldFile is configured with Release Signal Attribute = "myId". Its 'Hold'
> relationship routes back onto itself.
> 1. flowFile 1 { myId : "123" } enters HoldFile. It is routed to the 'Hold'
> relationship
> 2. flowFile 2 { flow.file.release.value : "123" } enters HoldFile. flowfile
> 1 is then routed to 'Release', and flow file 2 is removed from the session.
> Signal flow files will also copy their attributes to matching held files,
> unless otherwise indicated. This is what allows the output of Endpoint A to
> pass to Endpoint B, above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
