Re: [ANNOUNCE] Zike Yang as a new PMC member in Apache Pulsar
Congratulations! Thanks, Jiaqi Shen Jia Zhai 于2024年4月12日周五 08:49写道： > Cong~ > > On Thu, Apr 11, 2024 at 10:45 PM Max Xu wrote: > > > Congratulations! Zike > > > > Best, > > Max Xu > > > > > > On Thu, Apr 11, 2024 at 9:26 PM PengHui Li wrote: > > > > > The Apache Pulsar Project Management Committee (PMC) has invited > > > Zike Yang https://github.com/RobertIndie to join the PMC, > > > and we are pleased to announce that he has accepted. > > > > > > Zike Yang is actively driving the Golang client release, contributing > to > > > multiple > > > Pulsar repos, Golang client, CPP Client, Python Client, and Pulsar main > > > repo. > > > > > > On behalf of the Pulsar PMC, we extend a heartfelt welcome and > > > congratulations to Zike Yang. > > > > > > Regards, > > > Penghui > > > > > >
[DISCUSS] Why not split `memoryLimit` into `consumerMemoryLimit ` and `producerMemoryLimit `
Context. - PIP-74 https://github.com/apache/pulsar/wiki/PIP-74%3A-Pulsar-client-memory-limits - PR-8965 https://github.com/apache/pulsar/pull/8965 - PR-15216 https://github.com/apache/pulsar/pull/15216 Hello, community: There are some questions about PIP-74 I want to figure out. PIP-74 and its implementation specifie how to limit *client* memory. But in our scenario, the *client* is usually reused. It is more intuitive to limit a single *producer* or *consumer*. So why not let the producer/consumer have their own MemoryLimitController? And shoud we split the memoryLimit setting into consumerMemoryLimit and producerMemoryLimit? Are there any other considerations to limit *client* memory? If you know why it needs to be designed like this, please leave your comment. Thanks! Thanks, Jiaqi Shen
Re: [ANNOUNCE] Yunze Xu as a new PMC member in Apache Pulsar
Congrates! Great work, Yunze. Thanks, Jiaqi Shen Baodi Shi 于2022年12月30日周五 09:54写道： > Congrats! Yunze > > > > > Thanks, > Baodi Shi > > > 2022年12月30日 09:44，ZhangJian He 写道： > > > > Congratulations! Yunze > > > > Thanks > > ZhangJian He > > > > > > On Fri, 30 Dec 2022 at 09:25, Kai Wang wrote: > > > >> Congratulations! Yunze > >> > >> Thanks, > >> Kai > >> > >
Re: [DISCUSS] Move GitHub discussion notifications to commits@
+1 Thanks, Jiaqi Shen PengHui Li 于2022年12月26日周一 08:56写道： > Got it. Thanks for the explanation. > That sounds good to me to point the commits@ list for now. > > — Penghui > > > On Dec 24, 2022, at 02:05, Michael Marshall > wrote: > > > >> Is it better to point to user@ list? > > > > I think we should send these notifications to commits@ because the > > notifications are only notifications of activity and cannot be > > responded to directly via email. Also, these notifications do not > > "thread" correctly in some (all?) email providers, which makes it > > harder to quickly decide to participate in a given discussion. Lastly, > > commits@ is our "archive" list where we store GitHub notifications for > > issues and PRs. Putting discussion notifications follows this pattern. > > > > Note: the PR to update .asf.yaml was merged already, but we should > > continue discussing until we reach a consensus. > > > > Thanks, > > Michael > > > > > > > > > > On Fri, Dec 23, 2022 at 12:44 AM 丛搏 wrote: > >> > >> +1 for pointing to the user list. > >> > >> Thanks, > >> Bo > >> > >> Dave Fisher 于2022年12月23日周五 12:48写道： > >>> > >>> > >>> > >>> Sent from my iPhone > >>> > >>>> On Dec 22, 2022, at 7:00 PM, PengHui Li wrote: > >>>> > >>>> Is it better to point to user@ list? > >>>> I noticed that most discussions are user-facing issues(Requirements, > >>>> Questions) > >>> > >>> I agree. > >>> > >>> In addition, we should discuss in another thread how to guide user and > dev discussions. Guide where each occurs. > >>> > >>> Regards, > >>> Dave > >>>> > >>>> Thanks, > >>>> Penghui > >>>> > >>>>> On Fri, Dec 23, 2022 at 10:18 AM Yunze Xu > > >>>>> wrote: > >>>>> > >>>>> +1 > >>>>> > >>>>> Thanks, > >>>>> Yunze > >>>>> > >>>>>> On Fri, Dec 23, 2022 at 6:04 AM Michael Marshall < > mmarsh...@apache.org> > >>>>>> wrote: > >>>>>> > >>>>>> Hello Pulsar Community, > >>>>>> > >>>>>> We've had GitHub discussions enabled for a while now. I think > they're > >>>>>> a helpful way for users to ask questions. I also think they are > >>>>>> creating too many notifications to the dev@ list, which can make it > >>>>>> hard to keep up with PIPs, VOTEs, and other dev discussions. > >>>>>> > >>>>>> I propose we move these notifications to the commits@ list. This > >>>>>> change will make all GitHub notifications go to commits@. > >>>>>> > >>>>>> Any user/contributor that would like to receive discussion > >>>>>> notifications can subscribe via GitHub or via the commits mailing > >>>>>> list. > >>>>>> > >>>>>> Here is the relevant PR: > https://github.com/apache/pulsar/pull/19033 > >>>>>> > >>>>>> What are your thoughts? If there are no objections in the next > week, I > >>>>>> propose we merge the PR. > >>>>>> > >>>>>> Thanks, > >>>>>> Michael > >>>>> > >>> > >
[DISCUSS] [GO-Client] The behavior of Seek is different with Java Client
Hi all. I noticed that the behavior of go client Seek is different with Java client, which may confuse the users. More details here: https://github.com/apache/pulsar-client-go/issues/919. Overall, if go client executes `Seek(id)`, it will reset its position in `id` instead of `id+1` by default. It's different with Java Client. I think we should modify it to make sure that Go Client `Seek()` has the same behavior with Java Client. Even though it will bring the breaking change. Please feel free to leave your comments. Thanks, Jiaqi Shen
Re: [PROPOSAL] Website precommit and move the source of docs to the site repo
+1, it makes sense to me. Thanks, Jiaqi Shen Yu 于2022年12月19日周一 20:57写道： > Hi tison, > > Thanks for raising this up! > > Our community had a similar discussion previously and chose to "keep" the > doc repo stay in the Pulsar main repo at that time. > > [1] lists the pros and cons of "keep" and "not keep" solutions. > > I'm +0 on this proposal because I think the total scores of these two > solutions are almost equal after weighing the pros and cons. > > > > [1] https://lists.apache.org/thread/mf2xwntfgn84dq78ksqv22jk3drq6xb3 > > > On Mon, Dec 19, 2022 at 5:40 PM tison wrote: > > > Thanks for your feedback! > > > > @Asaf > > > > > pre-commit > > > > I mean CI checks before merging a patch. Currently, we don't run checks > for > > the content before merging them. This causes a series of syntax errors > and > > broken links issues. If we hold docs under site2 folder in the main repo > > and then copied to the site repo, we have two places to build such CI > > checks. What's worse, the checks for the main repo will be quite > > cumbersome (that you do some if-else logic in the whole Pulsar CI > > workflows, and do the sync sequentially in that workflow). > > > > If we hold the source of docs only in the site repo, we can extend the > > "precommit" workflow[1] I added recently to check for syntax errors and > > broken links also. > > > > > What does the apache/pulsar-site repo contain today? > > > > It should be covered by the documentation guide page[2]. It holds the > > source of the official website and the user docs are synced from the main > > repo. > > > > > What content do we have today in the pulsar repo related to the site? > > > > After issue-18014[3] is done, we host only user docs and some JSON > metadata > > in the main repo, which is synced by site_syncer.py[4]. > > > > > Can you explain that better? Are you saying pulsar source JARs contain > > the documentation? > > > > No. Source JARs contain only the Java files and necessary copyrights > info. > > The source release is, for example, > > > > > https://archive.apache.org/dist/pulsar/pulsar-2.10.2/apache-pulsar-2.10.2-src.tar.gz > > , > > which is extracted to 173M where 129M is occupied by the site2 folder. > > > > This also affects when developers do git clone to clone the repo. > > > > > I mean, if you wish to document a bug fix in 2.9.x, for example, would > > you do it in the 2.9.x branch under site2/docs or > > site2/website/versioned_docs/2.9.5? > > > > This is another question. Ideally, we should have hosted versioned docs > > associated with the specific version to that branch, like Apache Flink > does > > as I mentioned[5]. But we do not, and actually the situation is we update > > the versioned docs under the master branch and thus, the docs can be > synced > > properly. > > > > See also the "Alternatives" section in the original email. > > > > @All > > > > Since we don't have objections to the possible cons listed above or any > new > > ones, I'm going to create a tracking issue later this week and show what > > will be changed in PRs for further review. > > > > Best, > > tison. > > > > [1] > > > > > https://github.com/apache/pulsar-site/blob/f7abc615d57d9846ed093922d24bff952dc0e838/.github/workflows/ci-precommit.yml > > [2] > > > > > https://pulsar.apache.org/contribute/document-contribution/#source-repositories > > [3] https://github.com/apache/pulsar/issues/18014 > > [4] > > > > > https://github.com/apache/pulsar-site/blob/f7abc615d57d9846ed093922d24bff952dc0e838/tools/pytools/lib/execute/site_syncer.py > > [5] https://github.com/apache/flink/tree/master/docs > > > > > > PengHui Li 于2022年12月19日周一 16:26写道： > > > > > +1 > > > > > > I support moving them to the website repo. > > > > > > Thanks, > > > Penghui > > > > > > On Mon, Dec 19, 2022 at 12:04 PM Yunze Xu > > > > wrote: > > > > > > > +1. The most significant point to me is that we can preview all the > > > > content of the website without synchronizing contents from the > > > > apache/pulsar repo. > > > > > > > > Thanks, > > > > Yunze > > > > > > > > On Mon, Dec 19, 2022 at 9:53 AM Li Li wrote: > > > > > > > > > > +1, That’s a g
Re: [VOTE] PIP-224: Introduce TopicMessageId for consumer's MessageId related APIs
+1(non-binding) Thanks, Jiaqi Shen 于2022年12月5日周一 15:23写道： > +1(non-binding) > > Best, > Mattison > On Dec 5, 2022, 15:09 +0800, Zike Yang , wrote: > > +1(non-binding) > > > > Best, > > Zike Yang > > > > On Mon, Dec 5, 2022 at 2:41 PM Baodi Shi > wrote: > > > > > > +1(non-binding) > > > > > > Thanks, > > > Baodi Shi > > > > > > > > 2022年12月5日 12:51，Yunze Xu 写道： > > > > > > > > > > Hi all, > > > > > > > > > > I'm starting the vote for PIP-224: Introduce TopicMessageId for > > > > > consumer's MessageId related APIs: > > > > > https://github.com/apache/pulsar/issues/18616 > > > > > > > > > > Here is the discussion thread: > > > > > https://lists.apache.org/thread/jhqy65cdyxzmmxnfsjm8rv9pbk76noxy > > > > > > > > > > The vote will be open for at least 3 days. > > > > > > > > > > Thanks, > > > > > Yunze > > > >
Re: [DISCUSS] PIP-224: Introduce TopicMessageId for consumer's MessageId related APIs
This is make sense to me, +1 Thanks, Jiaqi Shen Yunze Xu 于2022年12月7日周三 13:51写道： > Hi Baodi, > > I decided not to change the behavior of the `negativeAcknowledge` > method. I just checked again that there is no exception signature for > this method and there is no asynchronous version like > `negativeAcknowledgeAsync`. To keep the API compatible, we should not > add an exception signature, which would be required if a > `PulsarClientException` was thrown. > > Thanks, > Yunze > > On Tue, Nov 29, 2022 at 10:12 PM Baodi Shi > wrote: > > > > Hi, Yunze: > > > > Thanks for your proposal. That Looks good to me. > > > > `negativeAcknowledge` also needs to add the same checks as the new > acknowledge interface. > > > > > This interface doesn't add any acknowledge overload because the > overloads are already too many. But it will make the behavior clear. > > I think since we exposed the TopicMessageId, it would be better to add > overloaded interfaces (even if the overloads are a lot). This can users to > clearly associate the use cases of MultiTopicConsumer and TopicMessageId. > > > > Also, while it's okay to use TopicMessageId param on a single consumer, > I guess we shouldn't allow users to use it. > > > > In this way, users are clearly aware that TopicMessageId is used when > using MultiTopicConsumer and MessageId is used when using > SingleTopicConsumer.(Maybe it's not a good idea) > > > > > > Thanks, > > Baodi Shi > > > > > 2022年11月29日 15:57，Yunze Xu 写道： > > > > > >> Is there a case where the user uses the messageId returned by the > > > producer to seek in the consumer? Is this a good behavior? > > > > > > Yes. I think it should be acceptable. To correct my previous point, > > > now I think the MessageId returned by send should also be able to be > > > applied for seek or acknowledge. > > > > > >> even with the > > > current proposal, it may return null when getting the topic from > > > TopicMessageId for backward compatibility. > > > > > > No. It may return null just because Java doesn't allow a non-null > > > returned value. The internal implementations of > > > TopicMessageId#getOwerTopic should return a non-null topic name to > > > avoid null check. > > > > > > When I mentioned **the implementation of getTopicName() must return > > > null**, the assumption is that MessageId#toByteArray serializes the > > > topic name if adding the `getTopicName()` method. However, in this > > > proposal, `TopicMessageId#toByteArray` won't. See the implementation > > > of `TopicMessageId#create`. It's only a wrapper for an arbitrary > > > MessageId implementation. > > > > > > Thanks, > > > Yunze > > > > > > On Tue, Nov 29, 2022 at 2:47 PM Zike Yang wrote: > > >> > > >> Hi Yunze, > > >> > > >> Thanks for your proposal. Quoted from your GitHub comments[0]: > > >> > > >>> There is also a case when MessageId is returned from Producer#send. > In this case, the returned MessageId should only used for serialization > > >> > > >> Is there a case where the user uses the messageId returned by the > > >> producer to seek in the consumer? Is this a good behavior? > > >> > > >>> If we added the method directly to MessageId, to keep the backward > compatibility, the implementation of getTopicName() must return null, which > is not a good design. > > >> > > >> I think it's a trade-off. If I understand correctly, even with the > > >> current proposal, it may return null when getting the topic from > > >> TopicMessageId for backward compatibility. The current > > >> TopicMessageIdImpl doesn't serialize the topic information. > > >> > > >> > > >> [0] > https://github.com/apache/pulsar/issues/18616#issuecomment-1328609346 > > >> > > >> Thanks, > > >> Zike Yang > > >> > > >> On Mon, Nov 28, 2022 at 12:22 PM Yunze Xu > wrote: > > >>> > > >>> Hi all, > > >>> > > >>> I've opened a PIP to discuss: > https://github.com/apache/pulsar/issues/18616. > > >>> > > >>> The consumer's MessageId related APIs have some hidden requirements > > >>> and flakiness and some behaviors are not documented well. This > > >>> proposal will introduce a TopicMessageId interface that exposes a > > >>> method to get a message's owner topic. > > >>> > > >>> P.S. There was an email [1] that didn't add the "[DISCUSS]" label, > > >>> which might be a little confusing. So I sent the email again for > > >>> discussion. Please do not reply to the previous email. > > >>> > > >>> [1] https://lists.apache.org/thread/6gj16pmrjk6ncsd30xrl20pr5ng6t61o > > >>> > > >>> Thanks, > > >>> Yunze > > >
Re: [DISCUSS] Remove restful producer component
+1 By the way, why the restful consumer still not be completed? Thanks, Jiaqi Shen Haiting Jiang 于2022年12月7日周三 15:56写道： > > I think we can remove it first because it is not a complete feature. > Anyone interested in working on it can find the code from the git history > and migrate it to another repo. > > Looks like it's not a complete implementation of PIP-64, but the REST > producer part seems to be working. > And some users may be using this partial feature, so we need to > consider the compatibility issue. > > It makes sense to move this out of the main repo. But I don't see a > strong reason to remove it directly. > We should try to provide transparent upgrading, but letting users > "find the code from the git history and migrate it to another repo" > doesn't seem like a good option here. This bar is too high for most > users. > > Thanks, > Haiting > > On Wed, Dec 7, 2022 at 1:42 PM wrote: > > > > Hi Haiting > > > Is it better to finish it first, and then remove this from the main > repo? > > I think we can remove it first because it is not a complete feature. > Anyone interested in working on it can find the code from the git history > and migrate it to another repo. > > > > Ps: it looks like the current implementation has some limits, maybe > another contributor like to use a different way. > > > > Please let me know if you have any concerns or if I am missing > something. Thanks a lot! > > > > Best > > Mattison > > On Dec 7, 2022, 12:10 +0800, Haiting Jiang , > wrote: > > > Hi Mattison > > > > > > What's the status of "moving this feature to another project" > > > Is it better to finish it first, and then remove this from the main > repo? > > > > > > Thanks, > > > Haiting > > > > > > On Tue, Dec 6, 2022 at 6:37 PM wrote: > > > > > > > > > > > > Hello, everyone. > > > > > > > > I'd like to start the discussion about `Remove restful producer > component`. The Github repository path is here[1]. > > > > > > > > As discussed before[2], moving this feature to another project is > better. Also, we didn't provide the consumer part in the pulsar repo. I > think it's a good chance to remove it after 2.11 is released. > > > > > > > > Best, > > > > Mattison > > > > > > > > [1] > https://github.com/apache/pulsar/tree/master/pulsar-broker/src/main/java/org/apache/pulsar/broker/rest > > > > [2] https://lists.apache.org/thread/fl2rbb6sxlzwgkt7ybx4jxfkfnlb27z1 > > > > > > > > >
Re: [DISCUSSION] Redesign the MessageId interface
Thanks, this is very inspiring to me. But I have a different opinion on `tostring`. >>You can only see a representation from `toString` method and got some output like "0:0:-1:0". I don't think `tostring` should be used in any serious case because it has no standard. There is no constraint on how the messageId should be converted to a string. For example, in go client, `tostring` is not being supported now. If go client should implement a `tostring` method, does go client' s`tostring` must follow the java implement like "0:0:-1:0"? If user do need a string/[]byte to record a messageId, `toByteArray` will be enough. In user side, most of the time , I think users don't really care about the "messageId string" is meaningful. I think `tostring` only should be used in debug. Thanks, Jiaqi Shen Joe F 于2022年11月9日周三 20:25写道： > Messageid is an identifier which identifies a message. How that id is > constructed, or what it contains should not matter to an application, and > an application should not assume anything about the implementation of that > id. > > >What about the partition index? We have a `TopicMetadata` interface that > returns the number of partitions. > > Partitioning is a first class concept, and is designed to be used by > application. How a partition is implemented should not be used by the > application . > > [ People violate this all the time, and I regret that Pulsar did not > provide get_Nth_topicpartion(), which led to people hardcoding it as > topicname-N. and using that directly. Now we are stuck with it.] > > Similarly batch index and batch size. Those are all logical concepts > exposed to the user. For eg: batch size is something the app is allowed to > tune > > >Even for ledger id and entry id, this pair represents a logic storage > position like the offset concept in Kafka > These are not equivalent. In Pulsar these are implementation details, > while in Kafka those are logical concepts. > > One might think that these are logical concepts in Pulsar, because if you > reverse engineer the current msgid implementation, you observe some > "properties". > > Ledger id/entry id are logical concepts in __Bookkeeper__ , not in Pulsar. > There is the Managed Ledger abstraction on top of BK, and then there is > Pulsar on top of ML. You will break two levels of abstraction to expose > ledger/entryid to an application > > An application should only care about the operations that can be done > with a messageId > > - getmsgid() to return the message id as an opaque object > > [Operators using one messageId ] > -serde, like tostring(). for storage/retrieval of message identifier > -getter/setter on logical properties of the message (partition id etc...) > -increment/decrement > > [Operators that take multiple messageIds] > -comparator > -range > > Those are the kind of operators Pulsar should provide to a user. > Applications should not implement these operators on their own by reverse > engineering the msgId. No application should be directly using ledgerid or > entryid for doing anything (math or logic), > > As long as Pulsar provides these operations with msgid to the > application, it should not care whether it's represented as "0:1:-1:-1" > or "a:b:-b-b", or "#xba4231!haxcy1826923f" or as a serialized binary > object or..whatever it may be. > > >>But it would be harder to know a tuple like "0:1:-1:-1" means. > > A user shouldn't have to know what this means. That's the point. > > Pulsar itself changed the messageId multiple times as it added > partitioning, batching and so on, and it might do so again. And bookkeeper > could change its representation of ledgers, (for eg, to uuids and byte > offsets) ML could replace BK with something else (for eg. a table in a > db.) Anything is possible - Pulsar would then just have to change the > implementation of the operator functions, and no application needs to be > rewritten. > > -j > > On Tue, Nov 8, 2022 at 6:05 PM Yunze Xu > wrote: > > > Hi Joe, > > > > Then what would we expect users to do with the MessageId? It should only > > be passed to Consumer#seek or ReaderBuilder#startMessageId? > > > > What about the partition index? We have a `TopicMetadata` interface that > > returns > > the number of partitions. If the partition is also "implementation > > details", should we expose > > this interface? Or should we support customizing a MessageRouter because > it > > returns the partition index? > > > > What about the batch index and batch size? For example, we have an > > enableBatchIndexAcknowle
Re: [ANNOUNCE] New Committer: Qiang Huang
Congratulations! (Are you BUPTer?樂 ) Thanks, Jiaqi Shen Jun Ma 于2022年10月14日周五 14:55写道： > Congratulations, Qiang! > > From: Xiangying Meng > Sent: Friday, October 14, 2022 14:17 > To: dev@pulsar.apache.org > Subject: Re: [ANNOUNCE] New Committer: Qiang Huang > > Congratulations Qiang Huang > > Thanks, > Xiangying > > On Fri, Oct 14, 2022 at 2:04 PM Haiting Jiang > wrote: > > > Congratulations! > > > > Best, > > Haiting > > > > On Fri, Oct 14, 2022 at 1:58 PM Max Xu wrote: > > > > > > Congratulations! Qiang > > > > > > Best, > > > Max Xu > > > > > > > > > On Fri, Oct 14, 2022 at 12:04 PM guo jiwei > wrote: > > > > > > > The Project Management Committee (PMC) for Apache Pulsar has invited > > > > Qiang Huang (https://github.com/hqebupt) to become a committer and > > > > we are pleased to announce that he has accepted. > > > > > > > > Qiang Huang (with Github id: hqebupt) contributed many improvements > > > > and bug fixes to Pulsar. > > > > > > > > Being a committer enables easier contribution to the project since > > > > there is no need to go via the patch submission process. This should > > > > enable better productivity. > > > > > > > > Welcome and Congratulations, Qiang Huang! > > > > > > > > Please join us in congratulating and welcoming Qiang Huang onboard! > > > > > > > > > > > > Regards > > > > Jiwei Guo on behalf of the Pulsar PMC > > > > > > >
Re: [DISCUSS] Release Pulsar Client C++ 3.0.0
+1 Thanks, Jiaqi Shen Xiangying Meng 于2022年10月8日周六 10:17写道： > +1 > > Thanks, > Xiangying > > > On Sat, Oct 8, 2022 at 9:43 AM Hang Chen wrote: > > > +1 > > > > Thanks, > > Hang > > > > Zike Yang 于2022年10月8日周六 09:19写道： > > > > > > +1 > > > > > > Thanks, > > > Zike Yang > > > > > > On Sat, Oct 8, 2022 at 9:17 AM PengHui Li wrote: > > > > > > > > +1 > > > > > > > > Regards, > > > > Penghui > > > > > > > > On Fri, Oct 7, 2022 at 11:34 PM tison wrote: > > > > > > > > > +1 cool! > > > > > > > > > > Best, > > > > > tison. > > > > > > > > > > > > > > > Baodi Shi 于2022年10月7日周五 23:31写道： > > > > > > > > > > > +1 > > > > > > > > > > > > Thanks, > > > > > > Baodi Shi > > > > > > > > > > > > > 在 2022年10月7日，22:00，Max Xu 写道： > > > > > > > > > > > > > > +1 > > > > > > > Thanks, Matteo. It's a great work! > > > > > > > > > > > > > > Best, > > > > > > > Max Xu > > > > > > > > > > > > > > > > > > > > >> On Fri, Oct 7, 2022 at 2:07 AM Matteo Merli < > mme...@apache.org> > > > > > wrote: > > > > > > >> > > > > > > >> We have moved the C++ client to its own separate repo > > > > > > >> (https://github.com/apache/pulsar-client-cpp) as part of > > PIP-209. > > > > > > >> > > > > > > >> There are several new features and fixes in the main branch > > that it > > > > > > >> would be good to get released, as well to get the new release > > process > > > > > > >> all flushed out. > > > > > > >> > > > > > > >> Matteo > > > > > > >> > > > > > > >> > > > > > > >> -- > > > > > > >> Matteo Merli > > > > > > >> > > > > > > >> > > > > > > > > > > > > > >
Re: [DISCUSS] Subscription Naming Rules
+1 Add a subscription name naming rule, for example: can only contain these characters "a-zA-Z_0-9" or "-=:.%". I think the subscription name should not contain special characters. It should keep the same naming rule with the topic. lordcheng10 于2022年10月1日周六 11:12写道： > Corresponding PR: > https://github.com/apache/pulsar/pull/17151 > > lordcheng10 于2022年10月1日周六 11:10写道： > > > Hello, Pulsar community: > > When creating a subscription, pulsar does not verify the name of the > > subscription, so the subscription name may contain some invisible > > characters in the created subscription. > > If the subscription name contains some invisible characters, when we > > delete the subscription by pulsar-admin, an error will be reported: > > Subscription not found. > > > > We have two ways to solve the problem: > > 1. Check whether the subscription name contains invisible characters, if > > it does, throw an exception and fail to create the subscription; > > 2. Add a subscription name naming rule, for example: can only contain > > these characters "a-zA-Z_0-9" or "-=:.%" > > > > > > What do you think, leave your opinion :) > > > > Thanks > > LinChen > > > > > > > > > -- Best Jiaqi Shen (Gleiphir2769)
