David, Going that @RunModes path - would we assume they support both run modes (once and scheduled) if the annotation is not present at all? I also dont think 'Once' by itself would ever be valid, right <i guess that was your manual intervention statement>
But yeah i'm not in love with the naming and generally I dont love the negative form. But it seems explicit/simple and opt-in in nature which seems favorable here. Thanks On Fri, Mar 14, 2025 at 12:42 PM David Handermann < exceptionfact...@apache.org> wrote: > Joe, > > Thanks for initiating the discussion on this API improvement. The core > concept sounds very useful. > > Regarding naming, I agree that DisallowRunOnce or RunOnceDisabled is > the most explicit. > > The other alternative that comes to mind is an enumeration with the > option for multiple values. For example, something like @RunModes, > with default options set to ONCE and SCHEDULED. Disabling Run Once > support would be implemented by setting only the SCHEDULED value. It > may not make sense to support only the ONCE mode, as it would require > manual intervention. > > As other Boolean-based annotations already exist, such as > PrimaryNodeOnly and TriggerSerially, I'm not opposed to the more > focused DisallowRunOnce approach. > > Regards, > David Handermann > > On Fri, Mar 14, 2025 at 1:18 PM Mark Payne <marka...@hotmail.com> wrote: > > > > Matt, PublishKafka could still run once. But I think ConsumeKafka would > not. The first time the processor is triggered, it requests data from the > client, which issues a request to the Kafka server. This is asynchronous > and hidden behind the poll() type of API, but it means that the first time > that you poll for records you will not receive any. > > > > Thanks > > -Mark > > > > > > > On Mar 14, 2025, at 2:08 PM, Matt Burgess <mattyb...@apache.org> > wrote: > > > > > > +1 from me, this would prevent the user from misunderstanding the > results > > > of running such processors once and having unmet expectations. One > thing I > > > would mention is to ensure there are NO use cases in which such > processors > > > won't be useful. The Merge processors are obvious as they need to run > more > > > than once in order to produce anything (and if the bins age off before > it's > > > run again the merge might not happen at all). Do the Kafka processors > need > > > to run more than once to produce results? For example I would think > > > PublishKafka should be able to publish a single message to a topic > when run > > > once? > > > > > > Thanks for raising the NIP, looking forward to the discussion! > > > > > > - Matt > > > > > > On Fri, Mar 14, 2025 at 1:35 PM Joe Witt <joew...@apache.org> wrote: > > > > > >> Team, > > >> > > >> Please see [1] > > >> > > >> In short - we need a way to prevent selection of 'run once' by users > for > > >> components that don't actually support it or work that way. > MergeContent > > >> is a great example but listing components and Kafka and likely many > others > > >> won't do anything useful with 'run once' invocations. > > >> > > >> I'll kick off a vote thread once discussion seems stable. > > >> > > >> Thanks > > >> Joe > > >> > > >> [1] https://issues.apache.org/jira/browse/NIP-5 > > >> > > >
