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
Hi Asaf,
I really don't know what's your concern but it seems you don't have much
understanding about Pulsar client/server protocol or you really would like
to block the PIP. I tried to answer your concerns but let me try again to
add more context about the implementation if that something can hel
On Tue, Jun 20, 2023 at 9:39 AM Rajan Dhabalia wrote:
> > So you say in that sentence that you will add the topic name into
> MessageIdData. MessageIdData is defined in PulsarApi.proto and is
> transferred over the wire, so how can you add the topic to this class
> without changing the wire proto
> So you say in that sentence that you will add the topic name into
MessageIdData. MessageIdData is defined in PulsarApi.proto and is
transferred over the wire, so how can you add the topic to this class
without changing the wire protocol?
Yes, the client creates a separate MessageId while creating
First, let me add some data that should be added to the Background section
of the PIP since I had to reverse engineer the code to understand that,
which is the opposite of the goal of a design document.
Pulsar Broker has a binary protocol, which allows the client to consume
messages, acknowle
Yes, the topic name will not be transferred and it's not part of the wire
protocol. Message uses MessageID protobuf data-structure to serialize and
deserialize MessageId and it doesn't change any behavior nor will transfer
any additional fields to the broker. and I would not like to introduce any
a
I think the topic name will not be transmitted to the broker.
The client side used the class generated by the protobuf message.
Or, we can create another class to avoid coupling issues, but it
will introduce more changes and copy data from one structure
to another. For the long-term, I think it sho
I don't get it - you say msgId is a data structure contained within
MessageId implementation, right? I presume msgId is the data structure the
client transmit to the server, so that means you are transmitting topic to
the server?
On Fri, May 12, 2023 at 7:45 AM Rajan Dhabalia wrote:
> Thank you
Thank you for sharing your knowledge about the PIP which should be created
before PR and I think everyone in the community knows about it. but you can
check the PR for context which was blocked for sometime and we decided to
create PIP with proto changes.
This PIP/PR tries to fix the issue where p
Hi Rajan,
A few comments on the PIP as I couldn't understand it fully as some pieces
of information is missing.
First, I would like to remind about the rules, that exists in the beginning
of the PIP template:
In this specific case
1. I would include explanation and detail the data structures
I'm talking about whether to add a new separate API. I'm concerned
about whether existing applications would be affected, no matter if
the existing implementation has the limitation. If yes, we should
document it in the PIP so that users can know that.
> it's a new optional field which would not b
Weill there are multiple things: it's a new optional field which would not
break the compatibility , also current messaegId serialization and
deserialization anyway only impact multi-topic consumer which is already
broken or has the limitation and, adding a new separate API for partitioned
topic is
It seems that `TopicMessageIdImpl#toByteArray` now could serialize the
optional topic field to the bytes. I didn't test it now but I have a
concern about whether it would bring a breaking change.
Assuming there are two applications (let's say A and B) based on an
older Pulsar client, A writes seri
Hi,
Pulsar api provides MessageId interface which is generally used by producer
and consumer applications to manage topic offset. Sometimes, these
applications would like to serialize and deserialize messageIds,
specifically consumer app which would like to persist messageId and ack
with those mes
14 matches
Mail list logo
