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 break the compatibility And yes, I just confirmed it with simple demos in my local env. So I'm +1 to this proposal. Thanks, Yunze On Tue, May 9, 2023 at 3:05 PM Rajan Dhabalia <rdhaba...@apache.org> wrote: > > 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 not only not acceptable but creates too much confusion for users > to use separate ack APIs for non-partition and partition topics and that > also breaks partitioned topic abstraction which we would like to avoid. > > Thanks, > Rajan > > On Mon, May 8, 2023 at 11:27 PM Yunze Xu <x...@apache.org> wrote: > > > 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 serialized bytes into a file, B reads > > bytes from the file and parses it to a MessageId. If A upgraded its > > Pulsar client to the latest while B did not, what would happen? Could > > B still get the correct MessageId or the bytes would not be able to > > parsed? > > > > P.S. it's better to add the API changes and potential breaking changes > > in the proposal. > > > > Thanks, > > Yunze > > > > On Tue, May 9, 2023 at 1:59 PM Rajan Dhabalia <rdhaba...@apache.org> > > wrote: > > > > > > 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 messageIds by deserializing them. However, right now Pulsar > > > doesn't support correct deserialization of multi-topic or > > partitioned-topic > > > because of that 1acknowledge` API call fails for those topics with below > > > error: > > > "Only TopicMessageId is allowed to acknowledge for a multi-topics > > consumer" > > > > > > MessageIdImpl stores id metadata into MessageIdData which doesn't contain > > > context about topic name to find out which topic belongs to this > > MessageID. > > > Therefore, we need to add topic-name into MessageIdData and allow > > > multi-topic/partitioned topics to deserialize messages correctly so, > > > consumer app can perform as expected. > > > > > > Please visit PIP for any suggestions: > > > https://github.com/apache/pulsar/issues/20221 > > > > > > This PIP is created with PR: https://github.com/apache/pulsar/pull/19944 > > > > > > Thanks, > > > Rajan > >
