Joe, Thanks for the reply. Yes, all things considered, the explicit negative DisallowRunOnce seems like the best option.
Regards, David Handermann On Fri, Mar 14, 2025 at 2:50 PM Joe Witt <joe.w...@gmail.com> wrote: > > 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 > > > >> > > > > >
