Hi all!
I am retrieving files thousands of files with FetchSFTP and from time to time
(say 1 per 10 min) I receive the following error.
FetchSFTP[id=e19a32eb-f9c6-13a0-38b4-45a726ec4273] Failed to fetch content for
StandardFlowFileRecord[uuid=82f316a2-f797-4d32-8aa8-3d1907b54e01,claim=StandardC
Valentina,
I have seen cases where the server will delete files after being touched by
the list(S)FTP processor, so if the fetch processor isn't fast enough it
gets deleted and causes that issue. If the file really does still exist on
the server then I would try a simple retry loop and see if a se
Hi Phillip,
I am leaning to the solution you are proposing - I can't identify the problem.
I am not using ListSFTP but executing a small script to obtain the list with
files using ExecuteStreamCommand.
Thanks & all the best
Valentina
From: Phillip Grenier
Sent:
Hi Chris,
I don't know much about gRPC, but the proto file is here:
https://github.com/apache/nifi/tree/main/nifi-nar-bundles/nifi-grpc-bundle/nifi-grpc-processors/src/main/resources/proto
I think you'd have to build a custom version of this NAR where you changed
the proto file and probably also
Chris,
Currently, the Invoke/Listen grpc processors are bound to a specific
proto IDL defined here:
https://github.com/apache/nifi/blob/main/nifi-nar-bundles/nifi-grpc-bundle/nifi-grpc-processors/src/main/resources/proto/flowfile_service.proto
When we originally put these together, there was
These scenarios are ripe for io race conditions between the sending process
(the thing putting files in the directory) and the receiving process
(nifi). It is vital to ensure the writer either changes the name when
done writing (best case) and the reader only looks at that pattern OR you
ensure t
Thanks Matt.
Seems like what I am trying to achieve is an antipattern.
On Wed, Aug 12, 2020 at 12:59 AM Matt Burgess wrote:
> Although this is an "unnatural" use of Groovy (and a conversation much
> better suited for the dev list :), it is possible to get at a map of
> defined variables (key and
