Wait 2025.10.2.19¶
Bundle¶
org.apache.nifi | nifi-standard-nar
Description¶
Routes incoming FlowFiles to the “wait” relationship until a matching release signal is stored in the distributed cache from a corresponding Notify processor. When a matching release signal is identified, a waiting FlowFile is routed to the “success” relationship. The release signal entry is then removed from the cache. The attributes of the FlowFile that produced the release signal are copied to the waiting FlowFile if the Attribute Cache Regex property of the corresponding Notify processor is set properly. If there are multiple release signals in the cache identified by the Release Signal Identifier, and the Notify processor is configured to copy the FlowFile attributes to the cache, then the FlowFile passing the Wait processor receives the union of the attributes of the FlowFiles that produced the release signals in the cache (identified by Release Signal Identifier). Waiting FlowFiles will be routed to “expired” if they exceed the Expiration Duration. If you need to wait for more than one signal, specify the desired number of signals via the “Target Signal Count” property. This is particularly useful with processors that split a source FlowFile into multiple fragments, such as SplitText. In order to wait for all fragments to be processed, connect the “original” relationship to a Wait processor, and the “splits” relationship to a corresponding Notify processor. Configure the Notify and Wait processors to use the “${fragment.identifier}” as the value of “Release Signal Identifier”, and specify “${fragment.count}” as the value of “Target Signal Count” in the Wait processor. It is recommended to use a prioritizer (for instance First In First Out) when using the “wait” relationship as a loop.
Exigences en matière d’entrées¶
REQUIRED
Prend en charge les propriétés dynamiques sensibles¶
false
Propriétés¶
Propriété |
Description |
|---|---|
attribute-copy-mode |
Indique comment traiter les attributs copiés à partir de FlowFiles entrant dans le processeur Notify |
distributed-cache-service |
Le Controller Service utilisé pour vérifier les signaux de libération provenant d’un processeur Notify correspondant |
expiration-duration |
Indique la durée après laquelle les FlowFiles en attente seront routés vers la relation “expired”. |
releasable-flowfile-count |
Une valeur ou le résultat d’une instruction de l’Attribute Expression Language qui sera évalué pour un FlowFile afin de déterminer le nombre de FlowFile libérables. Cette valeur spécifie combien de FlowFiles peuvent être libérés lorsque le nombre cible atteint le Target Signal Count. Zéro (0) a une signification particulière : tout nombre de FlowFiles peut être libéré tant que le nombre de signaux correspond à la cible. |
release-signal-id |
Valeur qui spécifie la clé d’un cache de signaux de libération spécifique. Pour décider si le FlowFile en cours de traitement par le processeur Wait doit être envoyé vers la relation “success” ou “wait”, le processeur vérifie les signaux présents dans le cache spécifié par cette clé. |
signal-counter-name |
Dans le cache (spécifié par l’Identifiant du signal de libération), les signaux peuvent appartenir à différents compteurs. Si cette propriété est spécifiée, le processeur vérifie le nombre de signaux présents dans le cache qui appartiennent à ce compteur particulier. Si elle n’est pas spécifiée, le processeur vérifie le nombre total de signaux dans le cache. |
target-signal-count |
Nombre de signaux devant être présents dans le cache (spécifié par l’Identifiant du signal de libération) pour que le FlowFile traité par le processeur Wait soit envoyé vers la relation “success”. Si le nombre de signaux dans le cache atteint cette valeur, le FlowFile est routé vers la relation “success” et le nombre de signaux dans le cache est diminué de cette valeur. Si Signal Counter Name est spécifié, ce processeur vérifie un compteur particulier ; sinon, il vérifie par rapport au nombre total de signaux dans le cache. |
wait-buffer-count |
Spécifiez le nombre maximum de FlowFiles entrants qui peuvent être mis en mémoire tampon pour vérifier s’ils peuvent avancer. Plus le tampon est grand, meilleures sont les performances, car cela réduit le nombre d’interactions avec le service de cache en regroupant les FlowFiles par identifiant de signal. Un seul identifiant de signal peut être traité par exécution de processeur. |
wait-mode |
Spécifie comment gérer un FlowFile en attente d’un signal de notification |
wait-penalty-duration |
Si configuré, lorsqu’un identifiant de signal a été traité mais n’a pas satisfait aux critères de libération, cet identifiant de signal est pénalisé et les FlowFiles ayant cet identifiant ne seront pas traités à nouveau pendant la période spécifiée, afin que cet identifiant ne bloque pas le traitement des autres. Cela peut être utile dans des cas d’utilisation où un processeur Wait doit traiter plusieurs identifiants de signal, et que chaque identifiant de signal comporte plusieurs FlowFiles, et que l’ordre de libération des FlowFiles est important au sein d’un identifiant de signal. L’ordre des FlowFile peut être configuré avec des Prioritizers. IMPORTANT : il existe une limite au nombre de signaux en file d’attente pouvant être traités, et le processeur Wait peut ne pas être en mesure de vérifier tous les identifiants de signaux en file d’attente. Voir Détails supplémentaires pour la meilleure pratique. |
Relations¶
Nom |
Description |
|---|---|
expired |
UnFlowFile qui a dépassé la durée d’expiration configurée sera routée vers cette relation |
failure |
Lorsque le cache est inaccessible, ou si le Release Signal Identifier est évalué à null ou vide, les FlowFiles sont routés vers cette relation. |
success |
Un FlowFile avec un signal de libération correspondant dans le cache sera routé vers cette relation |
wait |
Un FlowFile sans signal de libération correspondant dans le cache sera routé vers cette relation |
Écrit les attributs¶
Nom |
Description |
|---|---|
wait.start.timestamp |
Tous les FlowFiles auront un attribut “wait.start.timestamp”, qui définit l’horodatage initial (epoch) au moment où le fichier est entré pour la première fois dans ce processeur. Cet attribut est utilisé pour déterminer le délai d’expiration du FlowFile. Cet attribut n’est pas écrit lorsque le FlowFile est transféré vers failure, expired ou success. |
wait.counter.<counterName> |
Le nom de chaque compteur pour lequel au moins un signal a été présent dans le cache depuis la dernière fois que le cache était vide est copié dans le FlowFile actuel comme attribut. |