I'll continue this on Slack #dev and write the summary here.
Just to clarify any misunderstanding: My intention is to make Pulsar PIP
readable by anyone, which means: Adding the required background information
and explaining your idea in a way people can understand.
In light of this goal, I've in
Hello Devin,
The support for the avro scheme in Python function is just added and
released in v3.0.0
There is an example of using avro in Python function:
https://github.com/apache/pulsar/blob/660525e57ed35b74cb9204521d1fba02cc08c542/pulsar-functions/python-examples/avro_schema_test_function.py
Lari, would it be possible to explain in more detail the paint points
you're describing?
You say processing messages individually is slow; hence, processing them in
batches is better. I guess it's especially useful if you need to group a
batch based on a key. What I don't understand is how the fra
I think we can reference https://www.apache.org/foundation/voting.html
> Votes on code modifications follow a different model. In this scenario, a
> negative vote constitutes a veto , which the voting group (generally the PMC
> of a project) cannot override. Again, this model may be modified by
On Wed, Jun 21, 2023 at 10:27 AM Zixuan Liu wrote:
> I think we can reference https://www.apache.org/foundation/voting.html
>
> > Votes on code modifications follow a different model. In this scenario,
> a negative vote constitutes a veto , which the voting group (generally the
> PMC of a project
> mostly part of one enterprise and only their PIP/PRs are moving forward
No. PIPs are processed in a vendor natural bias. At least the difference
between lazy consensus and at least 3 +1 binding votes won't change it.
> help other community members to let them contribute to Pulsar so
I'm doing
On 2023/06/20 09:12:28 Enrico Olivelli wrote:
> > I am interested to know your thoughts on making the Pulsar Functions
> > runtime pluggable so that we can add new runtime types.
>
> I see that RuntimeFactory [1] is already customizable.
> What can we do more ?
> Are you talking about providing al
On 2023/06/21 07:21:31 Asaf Mesika wrote:
> Lari, would it be possible to explain in more detail the paint points
> you're describing?
Well the point of the pluggable Function runtime types is to support other
technologies. Let's forget the reactive messaging solution for a moment.
With a plugga
Looking into the discussion and reviewing our membership list, from module
experts' distribution perspective, I agree that specific modules can have
fewer PMC members overseeing.
According to my experience in the Flink community[1] and the natural that
improvement proposals are mainly about develo
+1 (binding)
Though I agree with Asaf that this proposal itself is not clear, I think the
design
Is easy to understand from the PR that a new field is added only for
serialization
and deserialization for a MessageId.
Thanks,
Yunze
> On Jun 21, 2023, at 03:08, Asaf Mesika wrote:
>
> -1 (non-b
Hi Rajan,
I think we discuss the newly added field in the
PulsarApi.proto at
https://github.com/apache/pulsar/pull/19944#discussion_r1153963425
But the proposal doesn't mention it.
Although I know why we need to add that field to the proto file
to avoid introducing many changes to the client side
> However, stats retrieval over HTTP API doesn’t work well in use cases
when users would like to access this API at a higher scale when a large
number of application nodes would like to use it over HTTP which could
overload brokers and sometimes makes broker irresponsive and impact admin
API perfor
Please find the response inline.
On Wed, Jun 21, 2023 at 5:53 PM PengHui Li wrote:
> > However, stats retrieval over HTTP API doesn’t work well in use cases
> when users would like to access this API at a higher scale when a large
> number of application nodes would like to use it over HTTP whic
13 matches
Mail list logo
