This was definitely changed at some point after KAFKA-495. The question is
when and why.
Here's the relevant code from that patch:
===================================================================
--- core/src/main/scala/kafka/utils/Topic.scala (revision 1390178)
+++ core/src/main/scala/kafka/utils/Topic.scala (working copy)
@@ -21,24 +21,21 @@
import util.matching.Regex
object Topic {
+ val legalChars = "[a-zA-Z0-9_-]"
-Todd
On Fri, Jul 10, 2015 at 1:02 PM, Grant Henke <ghe...@cloudera.com> wrote:
> kafka.common.Topic shows that currently period is a valid character and I
> have verified I can use kafka-topics.sh to create a new topic with a
> period.
>
>
> AdminUtils.createOrUpdateTopicPartitionAssignmentPathInZK currently uses
> Topic.validate before writing to Zookeeper.
>
> Should period character support be removed? I was under the same impression
> as Gwen, that a period was used by many as a way to "group" topics.
>
> The code is pasted below since its small:
>
> object Topic {
> val legalChars = "[a-zA-Z0-9\\._\\-]"
> private val maxNameLength = 255
> private val rgx = new Regex(legalChars + "+")
>
> val InternalTopics = Set(OffsetManager.OffsetsTopicName)
>
> def validate(topic: String) {
> if (topic.length <= 0)
> throw new InvalidTopicException("topic name is illegal, can't be
> empty")
> else if (topic.equals(".") || topic.equals(".."))
> throw new InvalidTopicException("topic name cannot be \".\" or
> \"..\"")
> else if (topic.length > maxNameLength)
> throw new InvalidTopicException("topic name is illegal, can't be
> longer than " + maxNameLength + " characters")
>
> rgx.findFirstIn(topic) match {
> case Some(t) =>
> if (!t.equals(topic))
> throw new InvalidTopicException("topic name " + topic + " is
> illegal, contains a character other than ASCII alphanumerics, '.', '_' and
> '-'")
> case None => throw new InvalidTopicException("topic name " + topic +
> " is illegal, contains a character other than ASCII alphanumerics, '.',
> '_' and '-'")
> }
> }
> }
>
> On Fri, Jul 10, 2015 at 2:50 PM, Todd Palino <tpal...@gmail.com> wrote:
>
> > I had to go look this one up again to make sure -
> > https://issues.apache.org/jira/browse/KAFKA-495
> >
> > The only valid character names for topics are alphanumeric, underscore,
> and
> > dash. A period is not supposed to be a valid character to use. If you're
> > seeing them, then one of two things have happened:
> >
> > 1) You have topic names that are grandfathered in from before that patch
> > 2) The patch is not working properly and there is somewhere in the broker
> > that the standard is not being enforced.
> >
> > -Todd
> >
> >
> > On Fri, Jul 10, 2015 at 12:13 PM, Brock Noland <br...@apache.org> wrote:
> >
> > > On Fri, Jul 10, 2015 at 11:34 AM, Gwen Shapira <gshap...@cloudera.com>
> > > wrote:
> > > > Hi Kafka Fans,
> > > >
> > > > If you have one topic named "kafka_lab_2" and the other named
> > > > "kafka.lab.2", the topic level metrics will be named kafka_lab_2 for
> > > > both, effectively making it impossible to monitor them properly.
> > > >
> > > > The reason this happens is that using "." in topic names is pretty
> > > > common, especially as a way to group topics into data centers,
> > > > relevant apps, etc - basically a work-around to our current lack of
> > > > name spaces. However, most metric monitoring systems using "." to
> > > > annotate hierarchy, so to avoid issues around metric names, Kafka
> > > > replaces the "." in the name with an underscore.
> > > >
> > > > This generates good metric names, but creates the problem with name
> > > collisions.
> > > >
> > > > I'm wondering if it makes sense to simply limit the range of
> > > > characters permitted in a topic name and disallow "_"? Obviously
> > > > existing topics will need to remain as is, which is a bit awkward.
> > >
> > > Interesting problem! Many if not most users I personally am aware of
> > > use "_" as a separator in topic names. I am sure that many users would
> > > be quite surprised by this limitation. With that said, I am sure
> > > they'd transition accordingly.
> > >
> > > >
> > > > If anyone has better backward-compatible solutions to this, I'm all
> > ears
> > > :)
> > > >
> > > > Gwen
> > >
> >
>
>
>
> --
> Grant Henke
> Solutions Consultant | Cloudera
> ghe...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
>
