I like this proposal as I can see it helping to reduce confusion in the Run
Once feature (which itself is amazing, by the way).
I do like Mark's idea of including a String argument, such as
DisallowRunOnce("because reasons"). It does not even have to be used
elsewhere, because at the least it can explain the reasons to other
developers.
I immediately thought that the Listen* processors can benefit from this, as
I have sometimes clicked Run Once on ListenHTTP by accident.
Good discussion,
-- Mike
On Fri, Mar 14, 2025 at 4:04 PM David Handermann <
exceptionfact...@apache.org> wrote:
> 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
> > > > >>
> > > >
> > >
>
