> Overall, I support setting naming restrictions on topic name and > subscription name. > But we must consider the compatibility since it would be a big break change. > One possible option would be adding a config entry in broker.conf for > the naming regex on topic and > subscriptions, with defaults to ".*" to keep the compatibility.
I agree to add a configuration to control whether to use strict naming checks for subscription and topic names. When we enable this configuration, the check of topic and subscription name reuses the org.apache.pulsar.common.naming.NamedEntity#checkName method? lordcheng10 <lordcheng1...@gmail.com> 于2022年10月2日周日 10:19写道： > > The namespace, cluster and topic names are checked by the > org.apache.pulsar.common.naming.NamedEntity#checkName method, which > requires names to contain only (a-zA-Z_0-9) or these special chars -=:.% . > > Sorry, the description is wrong here. > The namespace, cluster names are checked by the > org.apache.pulsar.common.naming.NamedEntity#checkName method, but the topic > name is the same as the subscription name and is not checked. > > lordcheng10 <lordcheng1...@gmail.com> 于2022年10月2日周日 10:05写道： > >> > I think the subscription name should not contain special characters. It >> should keep the same naming rule with the topic. >> >> The namespace, cluster and topic names are checked by the >> org.apache.pulsar.common.naming.NamedEntity#checkName method, which >> requires names to contain only (a-zA-Z_0-9) or these special chars -=:.% . >> >> So can we directly reuse the >> org.apache.pulsar.common.naming.NamedEntity#checkName method to check the >> subscription name? >> >> >> >> Haiting Jiang <jianghait...@gmail.com> 于2022年10月1日周六 17:01写道： >> >>> > I think the subscription name should not contain special characters. It >>> > should keep the same naming rule with the topic. >>> >>> Currently, we have entify naming restrictions on >>> cluster/tenant/namespace, but not on topic names, see [1]. >>> We can create topics like "persistent://public/default/###". >>> >>> Overall, I support setting naming restrictions on topic name and >>> subscription name. >>> But we must consider the compatibility since it would be a big break >>> change. >>> >>> One possible option would be adding a config entry in broker.conf for >>> the naming regex on topic and >>> subscriptions, with defaults to ".*" to keep the compatibility. >>> >>> [1] >>> https://github.com/apache/pulsar/blob/6651bbbab5b33f09cdde83de048d8116b2835de6/pulsar-common/src/main/java/org/apache/pulsar/common/naming/NamedEntity.java#L35 >>> >>> Thanks, >>> Haiting >>> >>> On Sat, Oct 1, 2022 at 11:52 AM Jiaqi Shen <gleiphir2...@gmail.com> >>> wrote: >>> > >>> > +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 <lordcheng1...@gmail.com> 于2022年10月1日周六 11:12写道： >>> > >>> > > Corresponding PR: >>> > > https://github.com/apache/pulsar/pull/17151 >>> > > >>> > > lordcheng10 <lordcheng1...@gmail.com> 于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) >>> >>
