Thanks for your reply. I'm sorry if my question seems confusing. I'm still learning how nifi works. I don't have any understand about how the framework works on the back end and incomplete understanding of the exposed interface. From my point view (an external process developer) asking to rollback the one flow file that failed (I don't want changes made to it incompletely) and lets the other n flowfiles move on seems reasonable. But I don't know what is happening in the session on the back end.
I likely don't really understand what happens on a rollback. Reading the developer's guide I got the impression that rollback disregards all changes made the session include transfers. It then returns the flowfiles to the queue. It would seem that a session is really finished and not usable after a rollback. So, I then don't understand how I can do my use case. I want to rollback (undo changes to a single flow file that failed) and then transfer it to the Failed relationship unchanged (or add the discard.reason to the attributes). I assume you mean "Run duration" when you refer to the 'scheduling' tab. I would love to understand better how that works. In the documentation, I only see a note about it in the User guide. But the developer's guide is silent. I don't see how that slider is enforced in the processor code. It seems that once the framework has ceded control to the processor it can run for as long as it wants. So more information about this would be great. Thanks again for the response. The information is always useful and enlighting. Devin On Tue, Mar 15, 2016 at 4:26 PM, Andrew Grande <agra...@hortonworks.com> wrote: > Devin, > > What you're asking for is a contradicting requirement. One trades > individual message transactional control (and necessary overhead) for the > higher throughput with micro-batching (but lesser control). In short, you > can't expect to rollback a message and not affect the whole batch. > > However, if you 'commit' this batch as received by your processor, and > take on the responsibility of storing, tracking and commit/rollback of > those yourself for downstream connection.... But then, why? > > In general, one should leverage NiFi 'Scheduling' tab and have the > micro-batching aspect controlled via the framework. Unless you really > really have a very good reason to do it yourself. > > Hope this helps, > Andrew > > > > > On 3/7/16, 5:00 PM, "Devin Fisher" <devin.fis...@perfectsearchcorp.com> > wrote: > > >Question about rollbacks. I have a processor that is grabbing a list of > >FlowFiles from session.get(100). It will then process each flow file one > at > >a time. I want to then be able if there is an error with a single > FlowFile > >to roll it back (and only this failed FlowFile) and transfer it to the > >FAILED relationship. But reading the javadoc for ProcessSession I don't > get > >the sense that I can do that. > > > >Is my workflow wrong, should I only get one at a time from the session and > >commit after each one? > > > >Devin >
