Best practices to handle multiple signal ids at a Wait processor

When a Wait processor is expected to process multiple signal ids, by configuring 'Release Signal Identifier' with a FlowFile attribute Expression Language, there are few things to consider in order to get the expected result. Processor configuration can vary based on your requirement. Also, you will need to have high level understanding on how Wait processor works: See following sections for common patterns

Release any FlowFile as soon as its signal is notified

This is the most common use case. FlowFiles are independent and can be released in any order.

Important configurations:

The following table illustrates the notified signal ids, queued FlowFiles and what will happen at each Wait run cycle.
# of Wait run Notified Signals Queue Index (FIFO) FlowFile UUID Signal ID  
1 B 1 a A This FlowFile is processed. But its signal is not found, and will be re-queued at the end of the queue.
2 b B  
3 c C  
2 B 1 b B This FlowFile is processed and since its signal is notified, this one will be released to 'success'.
2 c C  
3 a A  
3   1 c C This FlowFile will be processed at the next run.
2 a A  

Release higher priority FlowFiles in each signal id

Multiple FlowFiles share the same signal id, and the order of releasing a FlowFile is important.

Important configurations:

The following table illustrates the notified signal ids, queued FlowFiles and what will happen at each Wait run cycle. The example uses PriorityPrioritizer to control the order of processing FlowFiles within a signal id. If 'Wait Penalty Duration' is configured, Wait processor tracks unreleased signal ids and their penalty representing when they will be checked again.
# of Wait run Notified Signals Signal Penalties Queue Index (via 'priority' attribute) FlowFile UUID Signal ID 'priority' attr  
1 (00:01) B   1 a-1 A 1 This FlowFile is processed. But its signal is not found. Penalized.
2 b-1 B 1 Since a-1 and b-1 have the same priority '1', b-1 may be processed before a-1. You can add another Prioritizer to define more specific ordering.
3 b-2 B 2  
2 (00:02) B A (00:04) 1 a-1 A 1 This FlowFile is the first one according to the configured Prioritizer, but the signal id is penalized. So, this FlowFile is skipped at this execution.
2 b-1 B 1 This FlowFile is processed.
3 b-2 B 2  
3 (00:03)   A (00:04) 1 a-1 A 1 This FlowFile is the first one but is still penalized.
2 b-2 B 2 This FlowFile is processed, but its signal is not notified yet, thus will be penalized.
4 (00:04)   B (00:06) 1 a-1 A 1 This FlowFile is no longer penalized, and get processed. But its signal is not notified yet, thus will be penalized again.
2 b-2 B 2  

The importance of 'Run Duration' when 'Wait Penalty Duration' is used

There are limitation of number of signals can be checked based on the combination of 'Run Schedule' and 'Wait Penalize Duration'. If this limitation is engaged, some FlowFiles may not be processed and remain in the 'wait' relationship even if their signal ids are notified. Let's say Wait is configured with:

And there are 5 FlowFiles F1, F2 ... F5 in the 'wait' relationship. Then the signal for F5 is notified. Wait will work as follows:

Repeat above cycle, thus F5 will not be released until one of F1 ... F4 is released.

To mitigate such limitation, increasing 'Run Duration' is recommended. By increasing 'Run Duration', Wait processor can keep being scheduled for that duration. For example, with 'Run Duration' 500 ms, Wait should be able to loop through all 5 queued FlowFiles at a single run.