THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
CreateTopicResponse => ErrorCode ?(ErrorDescription)ErrorCode => int16ErrorDescription => string |
CreateTopicRequest requires topic name and either (partitions+replicas) or replicas assignment to create topic (validation is done on server side). You can also specify topic-level configs to create topic with (to use default set an empty array).
CreateTopicResponse is fairly simple - you receive error code (0 as always identifies NO_ERROR) and optionally error description. Usually it will hold the higher level exception that happened during command execution.
Alter Topic Request
AlterTopicRequest => TopicName ?(Partitions) ?(ReplicaAssignment) [AddedConfigEntry] [DeletedConfig]TopicName => string Partitions => int32ReplicaAssignment => stringAddedConfigEntry => ConfigKey ConfigValue ConfigKey => string ConfigValue => string DeletedConfig => string |
Alter Topic Response
AlterTopicResponse => ErrorCode ?(ErrorDescription)ErrorCode => int16ErrorDescription => string |
AlterTopicRequest is similar to previous, to specify topic level settings that should be removed, use DeletedConfig array (just setting keys). User can provide new partitions value, replica assignment or both.AlterTopicResponse is similar to CreateTopicResponse.
Delete Topic Request
DeleteTopicRequest => TopicNameTopicName => string |
Delete Topic Response
DeleteTopicResponse => ErrorCode ?(ErrorDescription)ErrorCode => int16ErrorDescription => string |
DeleteTopicRequest requires only topic name which should be deleted.DeleteTopicResponse is similar to CreateTopicResponse.
Describe Topic Request
DescribeTopicRequest => TopicNameTopicName => string |
Describe Topic Response
DescribeTopicResponse => ErrorCode ?(ErrorDescription) ?(TopicDescription)ErrorCode => int16ErrorDescription => stringTopicDescription => TopicName TopicConfigDetails [TopicPartitionDetails]TopicName => stringTopicConfigDetails => Partitions ReplicationFactor [ConfigEntry]Partitions => int32ReplicationFactor => int32 ConfigEntry => string stringTopicPartitionsDetails => PartitionId ?(Leader) [Replica] [ISR] PartitionId => int32Leader => int32 Replica => int32 ISR => int32 |
DescribeTopicRequest requires only topic name.DescribeTopicResponse besides errorCode and optional errorDescription which are used in the same way as in previous messages, holds optional (non empty if execution was successful) TopicDescription structure. See table below for details:
Field | Description |
|---|---|
TopicName | The name of the topic for which description is provided. |
TopicConfigDetails | A structure that holds basic replication details. |
Partitions | Number of partitions in give topic. |
Config | Topic-level setting and value which was overridden. |
TopicPartitionDetails | List describing replication details for each partition. |
PartitionId | Id of the partition. |
| Leader | Optional broekr-leader id for the described partition. |
| Replicas | List of broker ids serving a replica's role for the partition. |
| ISR | Same as replicas but includes only brokers that are known to be "in-sync" |
List Topics Request
ListTopicsRequest => |
List Topics Response
ListTopicsResponse => ErrorCode ?(ErrorDescription) ?(TopicsList)ErrorCode => int16ErrorDescription => stringTopicsList => [TopicName]TopicName => string |
ListTopicsRequest is a request with no arguments.ListTopicsResponse besides errorCode and optional errorDescription which are used in the same way as in previous messages, holds optional (non empty if execution was successful) two a list of topic names - one for deleted topics (marked for deletion) and the second one for ordinary, alive topicstopics in Kafka cluster.
Replication Commands Schema
Reassign Partitions
Reassign Partitions Request
ReassignPartitionRequest => ManualAssignmentManualAssignment => string |
Reassign Partitions Response
ReassignPartitionResponse => ErrorCode ?(ErrorDescription)ErrorCode => int16ErrorDescription => string |
ReassignPartitionsRequest requires manual partition assignment string. Parsing / validation is done on server. This request will only initiate partition reassignment and return immediately. It is client's responsibility to block the user continually sending VerifyReassignPartitionsRequest to check reassignment status. The format is the following:
{
"partitions": [
{"topic": "foo",
"partition": 1,
"replicas": [1,2,3] }
],
"version":1
}
ReassignPartitionResponse is similar to CreateTopicResponse.
Verify Reassign Partitions Request
VerifyReassignPartitionRequest => ManualAssignmentManualAssignment => string |
Verify Reassign Partitions Response
VerifyReassignPartitionResponse => [ReasignmnetResult] ErrorCode ?(ErrorDescription)ReasignmnetResult => TopicAndPartition ResultCodeTopicAndPartition => string int32 ResultCode => int16 ErrorCode => int16ErrorDescription => string |
VerifyReassignPartitionsRequest requires manual partition assignment string as with ReassignPartitionsRequest which status is verified by this request.
VerifyReassignPartitionResponse as with other Admin request may return error code and optional error description in case of failure. Otherwise a reassignment result map is returned. It holds reassignment status (-1 - reassignment failed, 0 - in progress, 1 - completed successfully).
Preferred Replica Leader Election
Preferred Replica Leader Election Request
PreferredReplicaLeaderElectionRequest => PartitionsSerializedPartitionsSerialized => string |
Preferred Replica Leader Election Response
PreferredReplicaLeaderElectionResponse => ErrorCode ?(ErrorDescription)ErrorCode => int16ErrorDescription => string |
PreferredReplicaLeaderEleactionRequest initiates preferred replica leader election procedure, similar to ReassignPartitionsRequest this request in intended to be non-blocking. The schema consist of one optional field - partitions in serialized form (json) for which procedure should be started. The format is the following:{"partitions":[
{"topic": "foo", "partition": 1},{"topic": "foobar", "partition": 2}
]}
PreferredReplicaLeaderElectionResponse is similar to CreateTopicResponse.
Status of the procedure may be checked with DescribeTopicRequest - the head of replicas list field and leader broker should be the same.
...