Enrico,
Thank you for your clarification.
> I would add a configuration parameter to allow the client to use this
> feature.
> So:
> - feature enabled -> everything works like in your patch
> - feature disabled -> the broker ignores *partial_producer_supported *and
> runs as before
Okay. That mak
sorry for the late reply, I missed this message.
Il giorno mar 7 dic 2021 alle ore 05:56 Yuri Mizushima <
yumiz...@yahoo-corp.jp> ha scritto:
> Enrico,
> Thank you for your comment.
>
> > IIUC with this change the client will control which metrics are reported
> by
> > the broker ?
>
> From the
Any thought on this?
--
Yuri Mizushima
yumiz...@yahoo-corp.jp
On 2021/12/07 13:57, "Yuri Mizushima" wrote:
Enrico,
Thank you for your comment.
> IIUC with this change the client will control which metrics are reported
by
> the broker ?
From the protocol perspective, y
Enrico,
Thank you for your comment.
> IIUC with this change the client will control which metrics are reported by
> the broker ?
From the protocol perspective, yes.
However, the main point of this change is not to "control" metrics by the
client side,
but to make the broker aggregate partitione
Yuri,
IIUC with this change the client will control which metrics are reported by
the broker ?
I am not sure it is a good idea, because metrics are usually managed by the
owners of the brokers, who sometimes are not the same who run the clients.
Also, I am not sure if this way it is possible for
Do you have any comments?
If there are no comments by Dec. 7, I will close the discussion and rebase the
PR commit to current master.
Regards,
--
Yuri Mizushima
yumiz...@yahoo-corp.jp
On 2021/11/16 15:46, "Yuri Mizushima" wrote:
Dear Pulsar community,
I have created a new PR
htt
Dear Pulsar community,
I have created a new PR https://github.com/apache/pulsar/pull/12401 for stats
aggregation,
but I didn't discuss about the wire protocol change. I hope we will discuss it
here.
Currently, partitioned producer can't aggregate by any key such as cnx,
producerId, producerNam
Dear Pulsar Community,
> I will submit the next PR about PartitionedTopicStats later.
I submitted the next PR for this PIP. If you have any suggestions, please
comment to this PR.
https://github.com/apache/pulsar/pull/10534
Regards,
--
Yuri Mizushima
yumiz...@yahoo-corp.jp
"Yuri Mizushima"
Dear Pulsar Community,
I submitted the PR for this PIP.
https://github.com/apache/pulsar/pull/10279
This is a part of implementations.
I will submit the next PR about PartitionedTopicStats later.
Regards,
--
Yuri Mizushima
yumiz...@yahoo-corp.jp
"Yuri Mizushima" wrote:
Sijie,
Aft
Sijie,
After sending previous mail, I watched meeting recording and understand about
authn/authz issue.
Therefore, I updated the PIP document.
https://github.com/apache/pulsar/wiki/PIP-79%3A-Reduce-redundant-producers-from-partitioned-producer
Regards,
--
Yuri Mizushima
yumiz...@yahoo-corp.jp
Sijie,
> If the lazy-loading approach sounds attractive to you and you like it,
> maybe the next step is to update the PIP, what do you think?
I think so too. I will update the PIP after discussing the authn/authz issue.
Regards,
--
Yuri Mizushima
yumiz...@yahoo-corp.jp
"Sijie Guo" wrote:
Hi Yuri,
Regarding the authn/authz issue, @Matteo Merli can
probably chime in more about that part.
If the lazy-loading approach sounds attractive to you and you like it,
maybe the next step is to update the PIP, what do you think?
- Sijie
On Mon, Feb 8, 2021 at 6:57 PM Yuri Mizushima
wrote:
Michael,
Thank you for your comment!
> Which Pulsar Clients will benefit from this proposal?
I think that this proposal will be useful to any clients.
In my schedule, if this proposal is accepted then I will implement this feature
to Java client.
If needed, then implement same feature to other c
Hi Yuri and Sijie,
I definitely like the idea of lazily creating producers as well as introducing
a way to provide custom routing logic.
Which Pulsar Clients will benefit from this proposal? I’d love to see this
feature in the go client.
Thanks,
Michael Marshall
> On Feb 7, 2021, at 9:53 PM,
Sijie,
Thank you for sharing!
First, I considered your suggestion.
I think these implementations sound good.
I think we should consider the State of partitioned producer: Ready,
Connecting, etc.
Currently, partitioned producer gets "Ready" only when all producers connect to
Broker correctly.
h
Hi Yuri,
In today's community meeting, Matteo shared some of his thoughts about this
PIP.
You can find some meeting notes here:
https://docs.google.com/document/d/19dXkVXeU2q_nHmkG8zURjKnYlvD96TbKf5KjYyASsOE/edit#bookmark=id.rezbt4xmjxpz
Matteo can also chime in as well.
- Sijie
On Sun, Jan 31
Sijie,
Thank you for your reply!
I'll check it.
Regards,
--
Yuri Mizushima
yumiz...@yahoo-corp.jp
"Sijie Guo" wrote:
Yuri,
Thank you for bringing this up! This is a super helpful proposal!
The problem is very similar to what an RPC framework (like Finagle) with
client-sid
Yuri,
Thank you for bringing this up! This is a super helpful proposal!
The problem is very similar to what an RPC framework (like Finagle) with
client-side load balancing has.
An RPC framework with a client-side load-balancing mechanism needs to send
requests across multiple nodes. If you have
I notice that PIP-78 has already assigned to another issue.
https://mail-archives.apache.org/mod_mbox/pulsar-dev/202101.mbox/%3CCAG%3DTQOrPH49v9ToDE_aeQzEiDC%2BEgSR61ERoqanpWfQGvEB_Vw%40mail.gmail.com%3E
So, I'll change the PIP number to 79.
https://github.com/apache/pulsar/wiki/PIP-79%3A-Reduce-r
Dear Pulsar community,
When partitioned producer connects to partitioned topic,
sometimes doesn't need to connect to all of partitions depending on rate,
routing mode, etc.
So, I drafted a PIP about reducing redundant producers from partitioned
producer.
I'd like to use system resources (e.g. co
20 matches
Mail list logo
