[
https://issues.apache.org/jira/browse/KAFKA-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark de Jong updated KAFKA-4425:
--------------------------------
Description:
With the release of Kafka 0.10.10 there are now commands to delete and create
topics via the TCP protocol see (KIP 4 and KAFKA-2945)
I've implemented this myself in my own driver.
When I send the following command to the current controller
"TopicDescriptor(topic = topic, nrPartitions = Some(3), replicationFactor =
Some(1), replicaAssignment = Seq.empty, config = Map())"
I'll get back a response with NoError
The server says this on the command line:
[2016-11-20 17:54:19,599] INFO Topic creation
{"version":1,"partitions":{"2":[1003],"1":[1001],"0":[1002]}}
(kafka.admin.AdminUtils$)
[2016-11-20 17:54:19,765] INFO [ReplicaFetcherManager on broker 1001] Removed
fetcher for partitions test212880282004727-1
(kafka.server.ReplicaFetcherManager)
[2016-11-20 17:54:19,789] INFO Completed load of log test212880282004727-1 with
1 log segments and log end offset 0 in 17 ms (kafka.log.Log)
[2016-11-20 17:54:19,791] INFO Created log for partition
[test212880282004727,1] in /kafka/kafka-logs-842dcf19f587 with properties
{compression.type -> producer, message.format.version -> 0.10.1-IV2,
file.delete.delay.ms -> 60000, max.message.bytes -> 1000012,
min.compaction.lag.ms -> 0, message.timestamp.type -> CreateTime,
min.insync.replicas -> 1, segment.jitter.ms -> 0, preallocate -> false,
min.cleanable.dirty.ratio -> 0.5, index.interval.bytes -> 4096,
unclean.leader.election.enable -> true, retention.bytes -> -1,
delete.retention.ms -> 86400000, cleanup.policy -> [delete], flush.ms ->
9223372036854775807, segment.ms -> 604800000, segment.bytes -> 1073741824,
retention.ms -> 604800000, message.timestamp.difference.max.ms ->
9223372036854775807, segment.index.bytes -> 10485760, flush.messages ->
9223372036854775807}. (kafka.log.LogManager)
However when I immediately fetch metadata (v2 call). I either get;
- The topic entry, but with no partitions data in it.
- The topic entry, but with the status NotLeaderForPartition
Is this an bug or I am missing something in my client?
was:
With the release of Kafka 0.10.10 there are now commands to delete and create
topics via the TCP protocol see (KIP 4 and KAFKA-2945)
I've implemented this myself in my own driver.
When I send the following command to the current controller
"TopicDescriptor(topic = topic, nrPartitions = Some(3), replicationFactor =
Some(1), replicaAssignment = Seq.empty, config = Map())"
I'll get back a response with NoError
The server says this on the command line:
<pre><code>
[2016-11-20 17:54:19,599] INFO Topic creation
{"version":1,"partitions":{"2":[1003],"1":[1001],"0":[1002]}}
(kafka.admin.AdminUtils$)
[2016-11-20 17:54:19,765] INFO [ReplicaFetcherManager on broker 1001] Removed
fetcher for partitions test212880282004727-1
(kafka.server.ReplicaFetcherManager)
[2016-11-20 17:54:19,789] INFO Completed load of log test212880282004727-1 with
1 log segments and log end offset 0 in 17 ms (kafka.log.Log)
[2016-11-20 17:54:19,791] INFO Created log for partition
[test212880282004727,1] in /kafka/kafka-logs-842dcf19f587 with properties
{compression.type -> producer, message.format.version -> 0.10.1-IV2,
file.delete.delay.ms -> 60000, max.message.bytes -> 1000012,
min.compaction.lag.ms -> 0, message.timestamp.type -> CreateTime,
min.insync.replicas -> 1, segment.jitter.ms -> 0, preallocate -> false,
min.cleanable.dirty.ratio -> 0.5, index.interval.bytes -> 4096,
unclean.leader.election.enable -> true, retention.bytes -> -1,
delete.retention.ms -> 86400000, cleanup.policy -> [delete], flush.ms ->
9223372036854775807, segment.ms -> 604800000, segment.bytes -> 1073741824,
retention.ms -> 604800000, message.timestamp.difference.max.ms ->
9223372036854775807, segment.index.bytes -> 10485760, flush.messages ->
9223372036854775807}. (kafka.log.LogManager)</code></pre>
However when I immediately fetch metadata (v2 call). I either get;
- The topic entry, but with no partitions data in it.
- The topic entry, but with the status NotLeaderForPartition
Is this an bug or I am missing something in my client?
> Topic created with CreateTopic command not listed in Metadata
> -------------------------------------------------------------
>
> Key: KAFKA-4425
> URL: https://issues.apache.org/jira/browse/KAFKA-4425
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.10.1.0
> Reporter: Mark de Jong
>
> With the release of Kafka 0.10.10 there are now commands to delete and create
> topics via the TCP protocol see (KIP 4 and KAFKA-2945)
> I've implemented this myself in my own driver.
> When I send the following command to the current controller
> "TopicDescriptor(topic = topic, nrPartitions = Some(3), replicationFactor =
> Some(1), replicaAssignment = Seq.empty, config = Map())"
> I'll get back a response with NoError
> The server says this on the command line:
> [2016-11-20 17:54:19,599] INFO Topic creation
> {"version":1,"partitions":{"2":[1003],"1":[1001],"0":[1002]}}
> (kafka.admin.AdminUtils$)
> [2016-11-20 17:54:19,765] INFO [ReplicaFetcherManager on broker 1001] Removed
> fetcher for partitions test212880282004727-1
> (kafka.server.ReplicaFetcherManager)
> [2016-11-20 17:54:19,789] INFO Completed load of log test212880282004727-1
> with 1 log segments and log end offset 0 in 17 ms (kafka.log.Log)
> [2016-11-20 17:54:19,791] INFO Created log for partition
> [test212880282004727,1] in /kafka/kafka-logs-842dcf19f587 with properties
> {compression.type -> producer, message.format.version -> 0.10.1-IV2,
> file.delete.delay.ms -> 60000, max.message.bytes -> 1000012,
> min.compaction.lag.ms -> 0, message.timestamp.type -> CreateTime,
> min.insync.replicas -> 1, segment.jitter.ms -> 0, preallocate -> false,
> min.cleanable.dirty.ratio -> 0.5, index.interval.bytes -> 4096,
> unclean.leader.election.enable -> true, retention.bytes -> -1,
> delete.retention.ms -> 86400000, cleanup.policy -> [delete], flush.ms ->
> 9223372036854775807, segment.ms -> 604800000, segment.bytes -> 1073741824,
> retention.ms -> 604800000, message.timestamp.difference.max.ms ->
> 9223372036854775807, segment.index.bytes -> 10485760, flush.messages ->
> 9223372036854775807}. (kafka.log.LogManager)
> However when I immediately fetch metadata (v2 call). I either get;
> - The topic entry, but with no partitions data in it.
> - The topic entry, but with the status NotLeaderForPartition
> Is this an bug or I am missing something in my client?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
