Hi I think it would be better/simpler to have one “out of service” concept to replace penalizing and yielding and when a plugin throws an exception then the plugin is deemed out of service, for a duration and so the connection to that plugin is disabled for the out of service duration.
When a plugin is out of service and the connection disabled - then resources that it uses will be freed(yielded). The question then is what the behaviour of the plugin before the disabled connection - should be. My thought is to tend towards stability and make sure resources are freed, so there may need to be a “domino effect”/cascade affect where all plugins before are gradually put out of service. With Kind Regards Michael de Courci [email protected] > On 28 Jan 2016, at 16:34, Mark Payne <[email protected]> wrote: > > All, > > I've been thinking about how we handle the concept of penalizing FlowFiles. > We've had a lot of questions > lately about how penalization works & the concept in general. Seems the > following problems exist: > > - Confusion about difference between penalization & yielding > - DFM sees option to configure penalization period on all processors, even if > they don't penalize FlowFiles. > - DFM cannot set penalty duration in 1 case and set a different value for a > different case (different relationship, for example). > - Developers often forget to call penalize() > - Developer has to determine whether or not to penalize when building a > processor. It is based on what the developer will > think may make sense, but in reality DFM's sometimes want to penalize things > when the processor doesn't behave that way. > > I'm wondering if it doesn't make sense to remove the concept of penalization > all together from Processors and instead > move the Penalty Duration so that it's a setting on the Connection. I think > this would clear up the confusion and give the DFM > more control over when/how long to penalize. Could set to the default to 30 > seconds for self-looping connections and no penalization > for other connections. > > Any thoughts? > > Thanks > -Mark
