The function could either be stateless or might have state.
All Pulsar Functions are triggered by events that happen on their input
Pulsar topics. In that sense they need Pulsar cluster.
This discussion is mainly around should the users be able to trigger the
invocation of the function that is out of band wrt their input topics.
On Mon, Mar 12, 2018 at 5:08 PM, Joe Francis <j...@oath.com.invalid> wrote:
> >The idea is that one can issue a curl command with payload to a Pulsar
> >Function running inside a Pulsar cluster and have the function work on the
> This is a stateless function? It can run on any framework that can execute
> a function - whats specific about this to need Pulsar?
> On Mon, Mar 12, 2018 at 4:47 PM, Sanjeev Kulkarni <sanjee...@gmail.com>
> > Hi folks,
> > There have been requests for triggering a Pulsar Function just like one
> > curl an AWS Lambda.
> > There can be several modes using different mechanisms that can be
> > supported. Just wanted to get community feedback around this.
> > The idea is that one can issue a curl command with payload to a Pulsar
> > Function running inside a Pulsar cluster and have the function work on
> > payload. The output of the function, if any, should be the response of
> > curl command.
> > There are several considerations
> > 1. Since Pulsar Functions consume from a topic, should we publish the
> > message to the incoming topic. What if a function consumes from multiple
> > input topics. In that case which topics should we publish on? Also note
> > that publishing on input topic will also affect other consumers beside
> > function in consideration.
> > 2. What is the side-affects of running functions this way. For example if
> > they modify any counters, that would be globally seen. Is this reasonable
> > behavior? What about any outputs being published to output topic?
> > 3. What is the best mechanism to implement such a functionality? If
> > side-effects are ok, then publish/consume is probably the easiest way to
> > implement it. Alternatively one can send the payload via grpc from the
> > brokers to the function instance to have it triggered. The state
> > side-effects concerns still exist in this scenario.
> > Any other concerns? Feedback is welcome.
> > Thanks!