Dave, Generally such a case where a processor combined with a flowfile can result in an error of some kind should have a failure relationship (or similarly named) and the flowfile should go there. However, some processors in certain cases will just rollback/fail and the data will sit in the original queue. That should only be the case when a processor itself is the problem (not that the combination of the processor and some flowfile is the problem). However, what has happened over time is that folks are using expression language enabled processor properties which take flow file attributes and the processor may not have been coded to consider the full user experience here. I'm not certain if this processor (ExecuteStreamCommand) is like this but hopefully that makes sense.
In short, the behavior you're describing should be treated like a bug and the processor logic should be improved. Thanks On Fri, Apr 26, 2019 at 12:12 PM David Gallagher < dgallag...@cleverdevices.com> wrote: > Hi - I have an issue where certain processors may hang due to > misconfiguration. For example, an ExecuteStreamCommand with an incorrect > path for the executable. In this scenario, the flowfile waits in the queue > for the processor and cannot proceed. It generates an error message, both > visually and in the log, but for the business process I'm working on we > want to detect this condition within the flow and then route an error > message to a queue. I was thinking about adding an expiration time for the > flowfile, but I wasn't sure how to capture that notification. Any ideas? Is > it possible to set up a processor that 'listens' for any expired flowfile > and outputs its attributes? > > > Thanks, > > > Dave >
