You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@kafka.apache.org by da...@apache.org on 2018/02/24 16:05:40 UTC
[kafka-site] branch asf-site updated: add 1.1.0 docs
This is an automated email from the ASF dual-hosted git repository.
damianguy pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/kafka-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 327fe93 add 1.1.0 docs
new 2509d02 Merge branch 'asf-site' of https://gitbox.apache.org/repos/asf/kafka-site into asf-site
327fe93 is described below
commit 327fe938442315cbce8213a054a8b8bee0ce54ff
Author: Damian Guy <da...@gmail.com>
AuthorDate: Sat Feb 24 16:03:42 2018 +0000
add 1.1.0 docs
---
11/api.html | 113 +
11/configuration.html | 418 +
11/connect.html | 551 +
11/design.html | 624 ++
11/documentation.html | 83 +
11/documentation/index.html | 18 +
11/documentation/streams/architecture.html | 19 +
11/documentation/streams/core-concepts.html | 19 +
.../streams/developer-guide/app-reset-tool.html | 19 +
.../streams/developer-guide/config-streams.html | 19 +
.../streams/developer-guide/datatypes.html | 19 +
.../streams/developer-guide/dsl-api.html | 19 +
.../streams/developer-guide/index.html | 19 +
.../developer-guide/interactive-queries.html | 19 +
.../streams/developer-guide/manage-topics.html | 19 +
.../streams/developer-guide/memory-mgmt.html | 19 +
.../streams/developer-guide/processor-api.html | 19 +
.../streams/developer-guide/running-app.html | 19 +
.../streams/developer-guide/security.html | 19 +
.../streams/developer-guide/testing.html | 19 +
.../streams/developer-guide/write-streams.html | 19 +
11/documentation/streams/index.html | 19 +
11/documentation/streams/quickstart.html | 19 +
11/documentation/streams/tutorial.html | 19 +
11/documentation/streams/upgrade-guide.html | 19 +
11/ecosystem.html | 18 +
11/generated/admin_client_config.html | 86 +
11/generated/connect_config.html | 156 +
11/generated/connect_metrics.html | 158 +
11/generated/connect_transforms.html | 228 +
11/generated/consumer_config.html | 122 +
11/generated/consumer_metrics.html | 77 +
11/generated/kafka_config.html | 365 +
11/generated/producer_config.html | 116 +
11/generated/producer_metrics.html | 78 +
11/generated/protocol_api_keys.html | 91 +
11/generated/protocol_errors.html | 81 +
11/generated/protocol_messages.html | 4749 ++++++++
11/generated/streams_config.html | 90 +
11/generated/topic_config.html | 59 +
11/images/consumer-groups.png | Bin 0 -> 26820 bytes
11/images/icons/NYT.jpg | Bin 0 -> 12605 bytes
11/images/icons/architecture--white.png | Bin 0 -> 812 bytes
11/images/icons/architecture.png | Bin 0 -> 818 bytes
11/images/icons/documentation--white.png | Bin 0 -> 1758 bytes
11/images/icons/documentation.png | Bin 0 -> 1642 bytes
11/images/icons/line.png | Bin 0 -> 676 bytes
11/images/icons/new-york.png | Bin 0 -> 3381 bytes
11/images/icons/rabobank.png | Bin 0 -> 3593 bytes
11/images/icons/tutorials--white.png | Bin 0 -> 1047 bytes
11/images/icons/tutorials.png | Bin 0 -> 985 bytes
11/images/icons/zalando.png | Bin 0 -> 2716 bytes
11/images/kafka-apis.png | Bin 0 -> 86640 bytes
11/images/kafka_log.png | Bin 0 -> 134321 bytes
11/images/kafka_multidc.png | Bin 0 -> 33959 bytes
11/images/kafka_multidc_complex.png | Bin 0 -> 38559 bytes
11/images/log_anatomy.png | Bin 0 -> 19579 bytes
11/images/log_cleaner_anatomy.png | Bin 0 -> 18638 bytes
11/images/log_compaction.png | Bin 0 -> 41414 bytes
11/images/log_consumer.png | Bin 0 -> 139658 bytes
11/images/mirror-maker.png | Bin 0 -> 6579 bytes
11/images/producer_consumer.png | Bin 0 -> 8691 bytes
11/images/streams-architecture-overview.jpg | Bin 0 -> 420929 bytes
11/images/streams-architecture-states.jpg | Bin 0 -> 147338 bytes
11/images/streams-architecture-tasks.jpg | Bin 0 -> 130435 bytes
11/images/streams-architecture-threads.jpg | Bin 0 -> 153622 bytes
11/images/streams-architecture-topology.jpg | Bin 0 -> 182199 bytes
11/images/streams-cache-and-commit-interval.png | Bin 0 -> 38648 bytes
11/images/streams-concepts-topology.jpg | Bin 0 -> 136983 bytes
11/images/streams-elastic-scaling-1.png | Bin 0 -> 88673 bytes
11/images/streams-elastic-scaling-2.png | Bin 0 -> 91141 bytes
11/images/streams-elastic-scaling-3.png | Bin 0 -> 88604 bytes
11/images/streams-interactive-queries-01.png | Bin 0 -> 80976 bytes
11/images/streams-interactive-queries-02.png | Bin 0 -> 73218 bytes
11/images/streams-interactive-queries-03.png | Bin 0 -> 79879 bytes
11/images/streams-interactive-queries-api-01.png | Bin 0 -> 84438 bytes
11/images/streams-interactive-queries-api-02.png | Bin 0 -> 100725 bytes
11/images/streams-session-windows-01.png | Bin 0 -> 49003 bytes
11/images/streams-session-windows-02.png | Bin 0 -> 55956 bytes
11/images/streams-stateful_operations.png | Bin 0 -> 123213 bytes
11/images/streams-table-duality-01.png | Bin 0 -> 14534 bytes
11/images/streams-table-duality-02.png | Bin 0 -> 56736 bytes
11/images/streams-table-duality-03.png | Bin 0 -> 91331 bytes
11/images/streams-table-updates-01.png | Bin 0 -> 78069 bytes
11/images/streams-table-updates-02.png | Bin 0 -> 91880 bytes
11/images/streams-time-windows-hopping.png | Bin 0 -> 110392 bytes
11/images/streams-time-windows-tumbling.png | Bin 0 -> 63888 bytes
11/images/streams-welcome.png | Bin 0 -> 80530 bytes
11/images/tracking_high_level.png | Bin 0 -> 82759 bytes
11/implementation.html | 319 +
11/introduction.html | 214 +
11/javadoc/allclasses-frame.html | 462 +
11/javadoc/allclasses-noframe.html | 462 +
11/javadoc/constant-values.html | 2255 ++++
11/javadoc/deprecated-list.html | 1035 ++
11/javadoc/help-doc.html | 214 +
11/javadoc/index-all.html | 11222 +++++++++++++++++++
11/javadoc/index.html | 74 +
.../kafka/clients/admin/AbstractOptions.html | 317 +
.../apache/kafka/clients/admin/AdminClient.html | 1076 ++
.../kafka/clients/admin/AdminClientConfig.html | 582 +
.../kafka/clients/admin/AlterConfigsOptions.html | 326 +
.../kafka/clients/admin/AlterConfigsResult.html | 243 +
.../clients/admin/AlterReplicaLogDirsOptions.html | 255 +
.../clients/admin/AlterReplicaLogDirsResult.html | 248 +
.../org/apache/kafka/clients/admin/Config.html | 331 +
.../clients/admin/ConfigEntry.ConfigSource.html | 370 +
.../clients/admin/ConfigEntry.ConfigSynonym.html | 311 +
.../apache/kafka/clients/admin/ConfigEntry.html | 472 +
.../kafka/clients/admin/CreateAclsOptions.html | 294 +
.../kafka/clients/admin/CreateAclsResult.html | 245 +
.../clients/admin/CreatePartitionsOptions.html | 304 +
.../clients/admin/CreatePartitionsResult.html | 245 +
.../kafka/clients/admin/CreateTopicsOptions.html | 326 +
.../kafka/clients/admin/CreateTopicsResult.html | 245 +
.../kafka/clients/admin/DeleteAclsOptions.html | 294 +
.../admin/DeleteAclsResult.FilterResult.html | 244 +
.../admin/DeleteAclsResult.FilterResults.html | 228 +
.../kafka/clients/admin/DeleteAclsResult.html | 273 +
.../kafka/clients/admin/DeleteRecordsOptions.html | 257 +
.../kafka/clients/admin/DeleteRecordsResult.html | 279 +
.../kafka/clients/admin/DeleteTopicsOptions.html | 294 +
.../kafka/clients/admin/DeleteTopicsResult.html | 245 +
.../apache/kafka/clients/admin/DeletedRecords.html | 265 +
.../kafka/clients/admin/DescribeAclsOptions.html | 294 +
.../kafka/clients/admin/DescribeAclsResult.html | 227 +
.../clients/admin/DescribeClusterOptions.html | 294 +
.../kafka/clients/admin/DescribeClusterResult.html | 261 +
.../clients/admin/DescribeConfigsOptions.html | 326 +
.../kafka/clients/admin/DescribeConfigsResult.html | 245 +
.../clients/admin/DescribeLogDirsOptions.html | 257 +
.../kafka/clients/admin/DescribeLogDirsResult.html | 243 +
.../admin/DescribeReplicaLogDirsOptions.html | 257 +
...ribeReplicaLogDirsResult.ReplicaLogDirInfo.html | 280 +
.../admin/DescribeReplicaLogDirsResult.html | 262 +
.../kafka/clients/admin/DescribeTopicsOptions.html | 294 +
.../kafka/clients/admin/DescribeTopicsResult.html | 245 +
.../kafka/clients/admin/KafkaAdminClient.html | 712 ++
.../kafka/clients/admin/ListTopicsOptions.html | 329 +
.../kafka/clients/admin/ListTopicsResult.html | 259 +
.../apache/kafka/clients/admin/NewPartitions.html | 316 +
.../org/apache/kafka/clients/admin/NewTopic.html | 384 +
.../kafka/clients/admin/RecordsToDelete.html | 295 +
.../kafka/clients/admin/TopicDescription.html | 353 +
.../apache/kafka/clients/admin/TopicListing.html | 298 +
.../apache/kafka/clients/admin/package-frame.html | 68 +
.../kafka/clients/admin/package-summary.html | 422 +
.../apache/kafka/clients/admin/package-tree.html | 193 +
.../clients/consumer/CommitFailedException.html | 262 +
.../apache/kafka/clients/consumer/Consumer.html | 651 ++
.../kafka/clients/consumer/ConsumerConfig.html | 1058 ++
.../clients/consumer/ConsumerInterceptor.html | 287 +
.../consumer/ConsumerRebalanceListener.html | 312 +
.../kafka/clients/consumer/ConsumerRecord.html | 614 +
.../kafka/clients/consumer/ConsumerRecords.html | 394 +
.../clients/consumer/InvalidOffsetException.html | 294 +
.../kafka/clients/consumer/KafkaConsumer.html | 1755 +++
.../kafka/clients/consumer/MockConsumer.html | 931 ++
.../consumer/NoOffsetForPartitionException.html | 333 +
.../kafka/clients/consumer/OffsetAndMetadata.html | 350 +
.../kafka/clients/consumer/OffsetAndTimestamp.html | 321 +
.../clients/consumer/OffsetCommitCallback.html | 225 +
.../consumer/OffsetOutOfRangeException.html | 310 +
.../clients/consumer/OffsetResetStrategy.html | 329 +
.../kafka/clients/consumer/RangeAssignor.html | 318 +
.../consumer/RetriableCommitFailedException.html | 329 +
.../kafka/clients/consumer/RoundRobinAssignor.html | 342 +
.../kafka/clients/consumer/StickyAssignor.html | 475 +
.../kafka/clients/consumer/package-frame.html | 47 +
.../kafka/clients/consumer/package-summary.html | 281 +
.../kafka/clients/consumer/package-tree.html | 206 +
.../clients/producer/BufferExhaustedException.html | 260 +
.../apache/kafka/clients/producer/Callback.html | 234 +
.../kafka/clients/producer/KafkaProducer.html | 972 ++
.../kafka/clients/producer/MockProducer.html | 793 ++
.../apache/kafka/clients/producer/Partitioner.html | 253 +
.../apache/kafka/clients/producer/Producer.html | 419 +
.../kafka/clients/producer/ProducerConfig.html | 967 ++
.../clients/producer/ProducerInterceptor.html | 310 +
.../kafka/clients/producer/ProducerRecord.html | 534 +
.../kafka/clients/producer/RecordMetadata.html | 507 +
.../kafka/clients/producer/package-frame.html | 34 +
.../kafka/clients/producer/package-summary.html | 211 +
.../kafka/clients/producer/package-tree.html | 171 +
11/javadoc/org/apache/kafka/common/Cluster.html | 569 +
.../org/apache/kafka/common/ClusterResource.html | 282 +
.../kafka/common/ClusterResourceListener.html | 234 +
.../org/apache/kafka/common/Configurable.html | 216 +
.../org/apache/kafka/common/KafkaException.html | 296 +
.../kafka/common/KafkaFuture.BaseFunction.html | 215 +
.../kafka/common/KafkaFuture.BiConsumer.html | 213 +
.../apache/kafka/common/KafkaFuture.Function.html | 246 +
.../org/apache/kafka/common/KafkaFuture.html | 597 +
11/javadoc/org/apache/kafka/common/Metric.html | 244 +
11/javadoc/org/apache/kafka/common/MetricName.html | 392 +
.../apache/kafka/common/MetricNameTemplate.html | 398 +
11/javadoc/org/apache/kafka/common/Node.html | 444 +
.../org/apache/kafka/common/PartitionInfo.html | 387 +
.../org/apache/kafka/common/Reconfigurable.html | 264 +
.../org/apache/kafka/common/TopicPartition.html | 327 +
.../apache/kafka/common/TopicPartitionInfo.html | 371 +
.../apache/kafka/common/TopicPartitionReplica.html | 342 +
.../kafka/common/acl/AccessControlEntry.html | 402 +
.../kafka/common/acl/AccessControlEntryFilter.html | 477 +
.../org/apache/kafka/common/acl/AclBinding.html | 366 +
.../apache/kafka/common/acl/AclBindingFilter.html | 438 +
.../org/apache/kafka/common/acl/AclOperation.html | 576 +
.../apache/kafka/common/acl/AclPermissionType.html | 425 +
.../org/apache/kafka/common/acl/package-frame.html | 27 +
.../apache/kafka/common/acl/package-summary.html | 174 +
.../org/apache/kafka/common/acl/package-tree.html | 142 +
.../annotation/InterfaceStability.Evolving.html | 151 +
.../annotation/InterfaceStability.Stable.html | 156 +
.../annotation/InterfaceStability.Unstable.html | 151 +
.../common/annotation/InterfaceStability.html | 263 +
.../kafka/common/annotation/package-frame.html | 25 +
.../kafka/common/annotation/package-summary.html | 163 +
.../kafka/common/annotation/package-tree.html | 132 +
.../apache/kafka/common/config/AbstractConfig.html | 728 ++
.../org/apache/kafka/common/config/Config.html | 254 +
.../config/ConfigDef.CompositeValidator.html | 252 +
.../kafka/common/config/ConfigDef.ConfigKey.html | 474 +
.../kafka/common/config/ConfigDef.Importance.html | 334 +
.../common/config/ConfigDef.NonEmptyString.html | 290 +
...onfigDef.NonEmptyStringWithoutControlChars.html | 286 +
.../common/config/ConfigDef.NonNullValidator.html | 273 +
.../kafka/common/config/ConfigDef.Range.html | 292 +
.../kafka/common/config/ConfigDef.Recommender.html | 240 +
.../apache/kafka/common/config/ConfigDef.Type.html | 406 +
.../kafka/common/config/ConfigDef.ValidList.html | 269 +
.../kafka/common/config/ConfigDef.ValidString.html | 269 +
.../kafka/common/config/ConfigDef.Validator.html | 221 +
.../kafka/common/config/ConfigDef.Width.html | 346 +
.../org/apache/kafka/common/config/ConfigDef.html | 1281 +++
.../kafka/common/config/ConfigException.html | 289 +
.../kafka/common/config/ConfigResource.Type.html | 334 +
.../apache/kafka/common/config/ConfigResource.html | 369 +
.../apache/kafka/common/config/ConfigValue.html | 427 +
.../apache/kafka/common/config/SaslConfigs.html | 678 ++
.../org/apache/kafka/common/config/SslConfigs.html | 893 ++
.../apache/kafka/common/config/TopicConfig.html | 899 ++
.../apache/kafka/common/config/package-frame.html | 50 +
.../kafka/common/config/package-summary.html | 277 +
.../apache/kafka/common/config/package-tree.html | 178 +
.../apache/kafka/common/errors/ApiException.html | 334 +
.../common/errors/AuthenticationException.html | 300 +
.../common/errors/AuthorizationException.html | 288 +
.../common/errors/BrokerNotAvailableException.html | 284 +
.../errors/ClusterAuthorizationException.html | 289 +
.../errors/ConcurrentTransactionsException.html | 270 +
.../common/errors/ControllerMovedException.html | 284 +
.../errors/CoordinatorLoadInProgressException.html | 295 +
.../errors/CoordinatorNotAvailableException.html | 330 +
.../common/errors/CorruptRecordException.html | 315 +
.../DelegationTokenAuthorizationException.html | 289 +
.../errors/DelegationTokenDisabledException.html | 284 +
.../errors/DelegationTokenExpiredException.html | 284 +
.../errors/DelegationTokenNotFoundException.html | 284 +
.../DelegationTokenOwnerMismatchException.html | 284 +
.../kafka/common/errors/DisconnectException.html | 350 +
.../common/errors/DuplicateSequenceException.html | 270 +
.../errors/FetchSessionIdNotFoundException.html | 287 +
.../common/errors/GroupAuthorizationException.html | 303 +
.../GroupCoordinatorNotAvailableException.html | 370 +
.../common/errors/GroupIdNotFoundException.html | 298 +
.../errors/GroupLoadInProgressException.html | 331 +
.../common/errors/GroupNotEmptyException.html | 298 +
.../common/errors/IllegalGenerationException.html | 308 +
.../common/errors/IllegalSaslStateException.html | 292 +
.../errors/InconsistentGroupProtocolException.html | 284 +
.../kafka/common/errors/InterruptException.html | 285 +
.../errors/InvalidCommitOffsetSizeException.html | 284 +
.../errors/InvalidConfigurationException.html | 284 +
.../errors/InvalidFetchSessionEpochException.html | 287 +
.../common/errors/InvalidFetchSizeException.html | 284 +
.../common/errors/InvalidGroupIdException.html | 284 +
.../common/errors/InvalidMetadataException.html | 318 +
.../common/errors/InvalidOffsetException.html | 291 +
.../common/errors/InvalidPartitionsException.html | 284 +
.../common/errors/InvalidPidMappingException.html | 270 +
.../errors/InvalidPrincipalTypeException.html | 284 +
.../errors/InvalidReplicaAssignmentException.html | 284 +
.../errors/InvalidReplicationFactorException.html | 284 +
.../common/errors/InvalidRequestException.html | 287 +
.../errors/InvalidRequiredAcksException.html | 270 +
.../errors/InvalidSessionTimeoutException.html | 284 +
.../common/errors/InvalidTimestampException.html | 285 +
.../kafka/common/errors/InvalidTopicException.html | 312 +
.../common/errors/InvalidTxnStateException.html | 270 +
.../common/errors/InvalidTxnTimeoutException.html | 286 +
.../kafka/common/errors/KafkaStorageException.html | 327 +
.../common/errors/LeaderNotAvailableException.html | 296 +
.../common/errors/LogDirNotFoundException.html | 297 +
.../kafka/common/errors/NetworkException.html | 320 +
.../common/errors/NotControllerException.html | 289 +
.../common/errors/NotCoordinatorException.html | 294 +
.../errors/NotCoordinatorForGroupException.html | 331 +
.../NotEnoughReplicasAfterAppendException.html | 277 +
.../common/errors/NotEnoughReplicasException.html | 314 +
.../errors/NotLeaderForPartitionException.html | 319 +
.../common/errors/OffsetMetadataTooLarge.html | 309 +
.../common/errors/OffsetOutOfRangeException.html | 291 +
.../errors/OperationNotAttemptedException.html | 272 +
.../common/errors/OutOfOrderSequenceException.html | 280 +
.../common/errors/PolicyViolationException.html | 285 +
.../common/errors/ProducerFencedException.html | 274 +
.../errors/ReassignmentInProgressException.html | 285 +
.../errors/RebalanceInProgressException.html | 308 +
.../errors/RecordBatchTooLargeException.html | 309 +
.../common/errors/RecordTooLargeException.html | 351 +
.../errors/ReplicaNotAvailableException.html | 296 +
.../kafka/common/errors/RetriableException.html | 313 +
.../common/errors/SaslAuthenticationException.html | 302 +
.../common/errors/SecurityDisabledException.html | 285 +
.../common/errors/SerializationException.html | 329 +
.../common/errors/SslAuthenticationException.html | 298 +
.../kafka/common/errors/TimeoutException.html | 314 +
.../common/errors/TopicAuthorizationException.html | 315 +
.../kafka/common/errors/TopicExistsException.html | 284 +
.../TransactionCoordinatorFencedException.html | 284 +
.../TransactionalIdAuthorizationException.html | 275 +
.../common/errors/UnknownMemberIdException.html | 308 +
.../common/errors/UnknownProducerIdException.html | 279 +
.../common/errors/UnknownServerException.html | 310 +
.../errors/UnknownTopicOrPartitionException.html | 322 +
.../UnsupportedByAuthenticationException.html | 285 +
.../UnsupportedForMessageFormatException.html | 286 +
.../errors/UnsupportedSaslMechanismException.html | 291 +
.../common/errors/UnsupportedVersionException.html | 292 +
.../kafka/common/errors/WakeupException.html | 262 +
.../apache/kafka/common/errors/package-frame.html | 104 +
.../kafka/common/errors/package-summary.html | 581 +
.../apache/kafka/common/errors/package-tree.html | 248 +
.../org/apache/kafka/common/header/Header.html | 217 +
.../org/apache/kafka/common/header/Headers.html | 321 +
.../apache/kafka/common/header/package-frame.html | 20 +
.../kafka/common/header/package-summary.html | 135 +
.../apache/kafka/common/header/package-tree.html | 127 +
.../org/apache/kafka/common/package-frame.html | 42 +
.../org/apache/kafka/common/package-summary.html | 257 +
.../org/apache/kafka/common/package-tree.html | 161 +
.../org/apache/kafka/common/resource/Resource.html | 422 +
.../kafka/common/resource/ResourceFilter.html | 437 +
.../apache/kafka/common/resource/ResourceType.html | 473 +
.../kafka/common/resource/package-frame.html | 24 +
.../kafka/common/resource/package-summary.html | 156 +
.../apache/kafka/common/resource/package-tree.html | 139 +
.../security/auth/AuthenticationContext.html | 229 +
.../security/auth/DefaultPrincipalBuilder.html | 331 +
.../kafka/common/security/auth/KafkaPrincipal.html | 451 +
.../security/auth/KafkaPrincipalBuilder.html | 217 +
.../auth/PlaintextAuthenticationContext.html | 288 +
.../common/security/auth/PrincipalBuilder.html | 273 +
.../security/auth/SaslAuthenticationContext.html | 305 +
.../common/security/auth/SecurityProtocol.html | 450 +
.../security/auth/SslAuthenticationContext.html | 303 +
.../kafka/common/security/auth/package-frame.html | 33 +
.../common/security/auth/package-summary.html | 196 +
.../kafka/common/security/auth/package-tree.html | 152 +
.../serialization/ByteArrayDeserializer.html | 314 +
.../common/serialization/ByteArraySerializer.html | 320 +
.../serialization/ByteBufferDeserializer.html | 314 +
.../common/serialization/ByteBufferSerializer.html | 320 +
.../common/serialization/BytesDeserializer.html | 314 +
.../common/serialization/BytesSerializer.html | 320 +
.../kafka/common/serialization/Deserializer.html | 268 +
.../common/serialization/DoubleDeserializer.html | 314 +
.../common/serialization/DoubleSerializer.html | 320 +
.../ExtendedDeserializer.Wrapper.html | 372 +
.../common/serialization/ExtendedDeserializer.html | 256 +
.../serialization/ExtendedSerializer.Wrapper.html | 382 +
.../common/serialization/ExtendedSerializer.html | 258 +
.../common/serialization/FloatDeserializer.html | 314 +
.../common/serialization/FloatSerializer.html | 320 +
.../common/serialization/IntegerDeserializer.html | 314 +
.../common/serialization/IntegerSerializer.html | 320 +
.../common/serialization/LongDeserializer.html | 314 +
.../kafka/common/serialization/LongSerializer.html | 320 +
.../apache/kafka/common/serialization/Serde.html | 272 +
.../serialization/Serdes.ByteArraySerde.html | 246 +
.../serialization/Serdes.ByteBufferSerde.html | 246 +
.../common/serialization/Serdes.BytesSerde.html | 246 +
.../common/serialization/Serdes.DoubleSerde.html | 246 +
.../common/serialization/Serdes.FloatSerde.html | 246 +
.../common/serialization/Serdes.IntegerSerde.html | 246 +
.../common/serialization/Serdes.LongSerde.html | 246 +
.../common/serialization/Serdes.ShortSerde.html | 246 +
.../common/serialization/Serdes.StringSerde.html | 246 +
.../common/serialization/Serdes.WrapperSerde.html | 339 +
.../apache/kafka/common/serialization/Serdes.html | 446 +
.../kafka/common/serialization/Serializer.html | 275 +
.../common/serialization/ShortDeserializer.html | 314 +
.../common/serialization/ShortSerializer.html | 320 +
.../common/serialization/StringDeserializer.html | 316 +
.../common/serialization/StringSerializer.html | 322 +
.../kafka/common/serialization/package-frame.html | 57 +
.../common/serialization/package-summary.html | 300 +
.../kafka/common/serialization/package-tree.html | 181 +
.../kafka/connect/connector/ConnectRecord.html | 512 +
.../apache/kafka/connect/connector/Connector.html | 489 +
.../kafka/connect/connector/ConnectorContext.html | 228 +
.../org/apache/kafka/connect/connector/Task.html | 256 +
.../kafka/connect/connector/package-frame.html | 25 +
.../kafka/connect/connector/package-summary.html | 166 +
.../kafka/connect/connector/package-tree.html | 132 +
.../apache/kafka/connect/data/ConnectSchema.html | 695 ++
11/javadoc/org/apache/kafka/connect/data/Date.html | 350 +
.../org/apache/kafka/connect/data/Decimal.html | 373 +
.../org/apache/kafka/connect/data/Field.html | 333 +
.../org/apache/kafka/connect/data/Schema.Type.html | 525 +
.../org/apache/kafka/connect/data/Schema.html | 679 ++
.../apache/kafka/connect/data/SchemaAndValue.html | 356 +
.../apache/kafka/connect/data/SchemaBuilder.html | 908 ++
.../apache/kafka/connect/data/SchemaProjector.html | 270 +
.../org/apache/kafka/connect/data/Struct.html | 638 ++
11/javadoc/org/apache/kafka/connect/data/Time.html | 350 +
.../org/apache/kafka/connect/data/Timestamp.html | 348 +
.../apache/kafka/connect/data/Values.Parser.html | 392 +
.../kafka/connect/data/Values.SchemaDetector.html | 271 +
.../org/apache/kafka/connect/data/Values.html | 868 ++
.../apache/kafka/connect/data/package-frame.html | 39 +
.../apache/kafka/connect/data/package-summary.html | 241 +
.../apache/kafka/connect/data/package-tree.html | 154 +
.../connect/errors/AlreadyExistsException.html | 290 +
.../kafka/connect/errors/ConnectException.html | 289 +
.../apache/kafka/connect/errors/DataException.html | 294 +
.../errors/IllegalWorkerStateException.html | 290 +
.../kafka/connect/errors/NotFoundException.html | 290 +
.../kafka/connect/errors/RetriableException.html | 290 +
.../connect/errors/SchemaBuilderException.html | 294 +
.../connect/errors/SchemaProjectorException.html | 294 +
.../apache/kafka/connect/errors/package-frame.html | 26 +
.../kafka/connect/errors/package-summary.html | 171 +
.../apache/kafka/connect/errors/package-tree.html | 155 +
.../kafka/connect/header/ConnectHeaders.html | 1058 ++
.../org/apache/kafka/connect/header/Header.html | 284 +
.../connect/header/Headers.HeaderTransform.html | 215 +
.../org/apache/kafka/connect/header/Headers.html | 818 ++
.../apache/kafka/connect/header/package-frame.html | 25 +
.../kafka/connect/header/package-summary.html | 162 +
.../apache/kafka/connect/header/package-tree.html | 136 +
.../apache/kafka/connect/sink/SinkConnector.html | 293 +
.../org/apache/kafka/connect/sink/SinkRecord.html | 478 +
.../org/apache/kafka/connect/sink/SinkTask.html | 564 +
.../apache/kafka/connect/sink/SinkTaskContext.html | 328 +
.../apache/kafka/connect/sink/package-frame.html | 25 +
.../apache/kafka/connect/sink/package-summary.html | 163 +
.../apache/kafka/connect/sink/package-tree.html | 140 +
.../kafka/connect/source/SourceConnector.html | 255 +
.../apache/kafka/connect/source/SourceRecord.html | 556 +
.../apache/kafka/connect/source/SourceTask.html | 439 +
.../kafka/connect/source/SourceTaskContext.html | 209 +
.../apache/kafka/connect/source/package-frame.html | 25 +
.../kafka/connect/source/package-summary.html | 166 +
.../apache/kafka/connect/source/package-tree.html | 140 +
.../apache/kafka/connect/storage/Converter.html | 259 +
.../kafka/connect/storage/ConverterConfig.html | 333 +
.../kafka/connect/storage/ConverterType.html | 361 +
.../kafka/connect/storage/HeaderConverter.html | 277 +
.../kafka/connect/storage/OffsetStorageReader.html | 249 +
.../connect/storage/SimpleHeaderConverter.html | 365 +
.../kafka/connect/storage/StringConverter.html | 444 +
.../connect/storage/StringConverterConfig.html | 354 +
.../kafka/connect/storage/package-frame.html | 32 +
.../kafka/connect/storage/package-summary.html | 198 +
.../apache/kafka/connect/storage/package-tree.html | 167 +
.../kafka/connect/transforms/Transformation.html | 266 +
.../kafka/connect/transforms/package-frame.html | 19 +
.../kafka/connect/transforms/package-summary.html | 133 +
.../kafka/connect/transforms/package-tree.html | 135 +
.../apache/kafka/connect/util/ConnectorUtils.html | 269 +
.../apache/kafka/connect/util/package-frame.html | 19 +
.../apache/kafka/connect/util/package-summary.html | 133 +
.../apache/kafka/connect/util/package-tree.html | 126 +
.../policy/AlterConfigPolicy.RequestMetadata.html | 299 +
.../kafka/server/policy/AlterConfigPolicy.html | 265 +
.../policy/CreateTopicPolicy.RequestMetadata.html | 362 +
.../kafka/server/policy/CreateTopicPolicy.html | 264 +
.../apache/kafka/server/policy/package-frame.html | 25 +
.../kafka/server/policy/package-summary.html | 162 +
.../apache/kafka/server/policy/package-tree.html | 142 +
11/javadoc/org/apache/kafka/streams/Consumed.html | 495 +
.../apache/kafka/streams/KafkaClientSupplier.html | 268 +
.../apache/kafka/streams/KafkaStreams.State.html | 435 +
.../kafka/streams/KafkaStreams.StateListener.html | 215 +
.../org/apache/kafka/streams/KafkaStreams.html | 895 ++
11/javadoc/org/apache/kafka/streams/KeyValue.html | 380 +
.../org/apache/kafka/streams/StreamsBuilder.html | 786 ++
.../streams/StreamsConfig.InternalConfig.html | 267 +
.../org/apache/kafka/streams/StreamsConfig.html | 1484 +++
.../org/apache/kafka/streams/StreamsMetrics.html | 400 +
.../kafka/streams/Topology.AutoOffsetReset.html | 324 +
11/javadoc/org/apache/kafka/streams/Topology.html | 1053 ++
.../streams/TopologyDescription.GlobalStore.html | 248 +
.../kafka/streams/TopologyDescription.Node.html | 255 +
.../streams/TopologyDescription.Processor.html | 225 +
.../kafka/streams/TopologyDescription.Sink.html | 225 +
.../kafka/streams/TopologyDescription.Source.html | 225 +
.../streams/TopologyDescription.Subtopology.html | 234 +
.../apache/kafka/streams/TopologyDescription.html | 285 +
.../apache/kafka/streams/TopologyTestDriver.html | 588 +
.../streams/errors/BrokerNotFoundException.html | 292 +
.../errors/DefaultProductionExceptionHandler.html | 309 +
...tionHandler.DeserializationHandlerResponse.html | 377 +
.../errors/DeserializationExceptionHandler.html | 251 +
.../streams/errors/InvalidStateStoreException.html | 296 +
.../apache/kafka/streams/errors/LockException.html | 291 +
.../errors/LogAndContinueExceptionHandler.html | 309 +
.../streams/errors/LogAndFailExceptionHandler.html | 309 +
.../streams/errors/ProcessorStateException.html | 291 +
...Handler.ProductionExceptionHandlerResponse.html | 376 +
.../streams/errors/ProductionExceptionHandler.html | 249 +
.../kafka/streams/errors/StreamsException.html | 289 +
.../streams/errors/TaskAssignmentException.html | 292 +
.../streams/errors/TaskIdFormatException.html | 292 +
.../streams/errors/TaskMigratedException.html | 297 +
.../streams/errors/TopologyBuilderException.html | 303 +
.../kafka/streams/errors/TopologyException.html | 291 +
.../apache/kafka/streams/errors/package-frame.html | 44 +
.../kafka/streams/errors/package-summary.html | 272 +
.../apache/kafka/streams/errors/package-tree.html | 179 +
.../apache/kafka/streams/kstream/Aggregator.html | 230 +
.../kafka/streams/kstream/ForeachAction.html | 220 +
.../apache/kafka/streams/kstream/GlobalKTable.html | 246 +
.../apache/kafka/streams/kstream/Initializer.html | 218 +
.../apache/kafka/streams/kstream/JoinWindows.html | 517 +
.../org/apache/kafka/streams/kstream/Joined.html | 385 +
.../kafka/streams/kstream/KGroupedStream.html | 2108 ++++
.../kafka/streams/kstream/KGroupedTable.html | 1226 ++
.../org/apache/kafka/streams/kstream/KStream.html | 3506 ++++++
.../kafka/streams/kstream/KStreamBuilder.html | 1736 +++
.../org/apache/kafka/streams/kstream/KTable.html | 3152 ++++++
.../kafka/streams/kstream/KeyValueMapper.html | 234 +
.../apache/kafka/streams/kstream/Materialized.html | 582 +
.../org/apache/kafka/streams/kstream/Merger.html | 217 +
.../apache/kafka/streams/kstream/Predicate.html | 222 +
.../org/apache/kafka/streams/kstream/Printed.html | 397 +
.../org/apache/kafka/streams/kstream/Produced.html | 469 +
.../org/apache/kafka/streams/kstream/Reducer.html | 228 +
.../apache/kafka/streams/kstream/Serialized.html | 358 +
.../streams/kstream/SessionWindowedKStream.html | 485 +
.../kafka/streams/kstream/SessionWindows.html | 358 +
.../kafka/streams/kstream/TimeWindowedKStream.html | 493 +
.../apache/kafka/streams/kstream/TimeWindows.html | 484 +
.../apache/kafka/streams/kstream/Transformer.html | 316 +
.../kafka/streams/kstream/TransformerSupplier.html | 216 +
.../kafka/streams/kstream/UnlimitedWindows.html | 437 +
.../apache/kafka/streams/kstream/ValueJoiner.html | 231 +
.../apache/kafka/streams/kstream/ValueMapper.html | 227 +
.../kafka/streams/kstream/ValueMapperWithKey.html | 230 +
.../kafka/streams/kstream/ValueTransformer.html | 321 +
.../streams/kstream/ValueTransformerSupplier.html | 218 +
.../streams/kstream/ValueTransformerWithKey.html | 293 +
.../kstream/ValueTransformerWithKeySupplier.html | 212 +
.../org/apache/kafka/streams/kstream/Window.html | 412 +
.../org/apache/kafka/streams/kstream/Windowed.html | 339 +
.../org/apache/kafka/streams/kstream/Windows.html | 390 +
.../kafka/streams/kstream/package-frame.html | 57 +
.../kafka/streams/kstream/package-summary.html | 360 +
.../apache/kafka/streams/kstream/package-tree.html | 171 +
.../org/apache/kafka/streams/package-frame.html | 44 +
.../org/apache/kafka/streams/package-summary.html | 272 +
.../org/apache/kafka/streams/package-tree.html | 166 +
.../AbstractNotifyingBatchingRestoreCallback.html | 367 +
.../AbstractNotifyingRestoreCallback.html | 343 +
.../kafka/streams/processor/AbstractProcessor.html | 349 +
.../processor/BatchingStateRestoreCallback.html | 229 +
.../kafka/streams/processor/Cancellable.html | 209 +
.../streams/processor/DefaultPartitionGrouper.html | 291 +
.../streams/processor/FailOnInvalidTimestamp.html | 314 +
.../processor/LogAndSkipOnInvalidTimestamp.html | 315 +
.../kafka/streams/processor/PartitionGrouper.html | 229 +
.../apache/kafka/streams/processor/Processor.html | 282 +
.../kafka/streams/processor/ProcessorContext.html | 621 +
.../kafka/streams/processor/ProcessorSupplier.html | 214 +
.../kafka/streams/processor/PunctuationType.html | 327 +
.../apache/kafka/streams/processor/Punctuator.html | 210 +
.../streams/processor/StateRestoreCallback.html | 217 +
.../streams/processor/StateRestoreListener.html | 283 +
.../apache/kafka/streams/processor/StateStore.html | 321 +
.../streams/processor/StateStoreSupplier.html | 275 +
.../kafka/streams/processor/StreamPartitioner.html | 240 +
.../org/apache/kafka/streams/processor/TaskId.html | 445 +
.../kafka/streams/processor/TaskMetadata.html | 321 +
.../kafka/streams/processor/ThreadMetadata.html | 351 +
.../streams/processor/TimestampExtractor.html | 232 +
.../processor/TopologyBuilder.AutoOffsetReset.html | 322 +
.../processor/TopologyBuilder.TopicsInfo.html | 379 +
.../kafka/streams/processor/TopologyBuilder.html | 1464 +++
.../UsePreviousTimeOnInvalidTimestamp.html | 314 +
.../processor/WallclockTimestampExtractor.html | 279 +
.../kafka/streams/processor/package-frame.html | 52 +
.../kafka/streams/processor/package-summary.html | 326 +
.../kafka/streams/processor/package-tree.html | 170 +
.../org/apache/kafka/streams/state/HostInfo.html | 333 +
.../streams/state/KeyValueBytesStoreSupplier.html | 188 +
.../kafka/streams/state/KeyValueIterator.html | 248 +
.../apache/kafka/streams/state/KeyValueStore.html | 305 +
.../kafka/streams/state/QueryableStoreType.html | 238 +
.../kafka/streams/state/QueryableStoreTypes.html | 298 +
.../kafka/streams/state/ReadOnlyKeyValueStore.html | 292 +
.../kafka/streams/state/ReadOnlySessionStore.html | 253 +
.../kafka/streams/state/ReadOnlyWindowStore.html | 326 +
.../kafka/streams/state/RocksDBConfigSetter.html | 214 +
.../streams/state/SessionBytesStoreSupplier.html | 227 +
.../apache/kafka/streams/state/SessionStore.html | 321 +
.../apache/kafka/streams/state/StateSerdes.html | 476 +
.../apache/kafka/streams/state/StoreBuilder.html | 317 +
.../apache/kafka/streams/state/StoreSupplier.html | 249 +
.../state/Stores.InMemoryKeyValueFactory.html | 283 +
.../streams/state/Stores.KeyValueFactory.html | 233 +
.../state/Stores.PersistentKeyValueFactory.html | 323 +
.../kafka/streams/state/Stores.StoreFactory.html | 383 +
.../kafka/streams/state/Stores.ValueFactory.html | 385 +
.../org/apache/kafka/streams/state/Stores.html | 514 +
.../kafka/streams/state/StreamsMetadata.html | 407 +
.../streams/state/WindowBytesStoreSupplier.html | 281 +
.../apache/kafka/streams/state/WindowStore.html | 263 +
.../kafka/streams/state/WindowStoreIterator.html | 236 +
.../apache/kafka/streams/state/package-frame.html | 46 +
.../kafka/streams/state/package-summary.html | 285 +
.../apache/kafka/streams/state/package-tree.html | 193 +
.../kafka/streams/test/ConsumerRecordFactory.html | 707 ++
.../apache/kafka/streams/test/OutputVerifier.html | 455 +
.../apache/kafka/streams/test/package-frame.html | 20 +
.../apache/kafka/streams/test/package-summary.html | 140 +
.../apache/kafka/streams/test/package-tree.html | 127 +
11/javadoc/overview-frame.html | 47 +
11/javadoc/overview-summary.html | 235 +
11/javadoc/overview-tree.html | 756 ++
11/javadoc/package-list | 28 +
11/javadoc/resources/background.gif | Bin 0 -> 2313 bytes
11/javadoc/resources/tab.gif | Bin 0 -> 291 bytes
11/javadoc/resources/titlebar.gif | Bin 0 -> 10701 bytes
11/javadoc/resources/titlebar_end.gif | Bin 0 -> 849 bytes
11/javadoc/serialized-form.html | 1232 ++
11/javadoc/stylesheet.css | 474 +
11/js/templateData.js | 24 +
11/migration.html | 34 +
11/ops.html | 1670 +++
11/protocol.html | 230 +
11/quickstart.html | 300 +
11/security.html | 1075 ++
11/streams/architecture.html | 173 +
11/streams/core-concepts.html | 215 +
11/streams/developer-guide/app-reset-tool.html | 196 +
11/streams/developer-guide/config-streams.html | 761 ++
11/streams/developer-guide/datatypes.html | 223 +
11/streams/developer-guide/dsl-api.html | 3207 ++++++
11/streams/developer-guide/index.html | 105 +
.../developer-guide/interactive-queries.html | 530 +
11/streams/developer-guide/manage-topics.html | 129 +
11/streams/developer-guide/memory-mgmt.html | 241 +
11/streams/developer-guide/processor-api.html | 429 +
11/streams/developer-guide/running-app.html | 197 +
11/streams/developer-guide/security.html | 184 +
11/streams/developer-guide/testing.html | 315 +
11/streams/developer-guide/write-streams.html | 248 +
11/streams/index.html | 374 +
11/streams/quickstart.html | 389 +
11/streams/tutorial.html | 665 ++
11/streams/upgrade-guide.html | 460 +
11/toc.html | 158 +
11/upgrade.html | 705 ++
11/uses.html | 81 +
665 files changed, 219531 insertions(+)
diff --git a/11/api.html b/11/api.html
new file mode 100644
index 0000000..9777186
--- /dev/null
+++ b/11/api.html
@@ -0,0 +1,113 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<script id="api-template" type="text/x-handlebars-template">
+ Kafka includes five core apis:
+ <ol>
+ <li>The <a href="#producerapi">Producer</a> API allows applications to send streams of data to topics in the Kafka cluster.
+ <li>The <a href="#consumerapi">Consumer</a> API allows applications to read streams of data from topics in the Kafka cluster.
+ <li>The <a href="#streamsapi">Streams</a> API allows transforming streams of data from input topics to output topics.
+ <li>The <a href="#connectapi">Connect</a> API allows implementing connectors that continually pull from some source system or application into Kafka or push from Kafka into some sink system or application.
+ <li>The <a href="#adminapi">AdminClient</a> API allows managing and inspecting topics, brokers, and other Kafka objects.
+ </ol>
+
+ Kafka exposes all its functionality over a language independent protocol which has clients available in many programming languages. However only the Java clients are maintained as part of the main Kafka project, the others are available as independent open source projects. A list of non-Java clients is available <a href="https://cwiki.apache.org/confluence/display/KAFKA/Clients">here</a>.
+
+ <h3><a id="producerapi" href="#producerapi">2.1 Producer API</a></h3>
+
+ The Producer API allows applications to send streams of data to topics in the Kafka cluster.
+ <p>
+ Examples showing how to use the producer are given in the
+ <a href="/{{version}}/javadoc/index.html?org/apache/kafka/clients/producer/KafkaProducer.html" title="Kafka {{dotVersion}} Javadoc">javadocs</a>.
+ <p>
+ To use the producer, you can use the following maven dependency:
+
+ <pre class="brush: xml;">
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-clients</artifactId>
+ <version>{{fullDotVersion}}</version>
+ </dependency>
+ </pre>
+
+ <h3><a id="consumerapi" href="#consumerapi">2.2 Consumer API</a></h3>
+
+ The Consumer API allows applications to read streams of data from topics in the Kafka cluster.
+ <p>
+ Examples showing how to use the consumer are given in the
+ <a href="/{{version}}/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html" title="Kafka {{dotVersion}} Javadoc">javadocs</a>.
+ <p>
+ To use the consumer, you can use the following maven dependency:
+ <pre class="brush: xml;">
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-clients</artifactId>
+ <version>{{fullDotVersion}}</version>
+ </dependency>
+ </pre>
+
+ <h3><a id="streamsapi" href="#streamsapi">2.3 Streams API</a></h3>
+
+ The <a href="#streamsapi">Streams</a> API allows transforming streams of data from input topics to output topics.
+ <p>
+ Examples showing how to use this library are given in the
+ <a href="/{{version}}/javadoc/index.html?org/apache/kafka/streams/KafkaStreams.html" title="Kafka {{dotVersion}} Javadoc">javadocs</a>
+ <p>
+ Additional documentation on using the Streams API is available <a href="/{{version}}/documentation/streams">here</a>.
+ <p>
+ To use Kafka Streams you can use the following maven dependency:
+
+ <pre class="brush: xml;">
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-streams</artifactId>
+ <version>{{fullDotVersion}}</version>
+ </dependency>
+ </pre>
+
+ <h3><a id="connectapi" href="#connectapi">2.4 Connect API</a></h3>
+
+ The Connect API allows implementing connectors that continually pull from some source data system into Kafka or push from Kafka into some sink data system.
+ <p>
+ Many users of Connect won't need to use this API directly, though, they can use pre-built connectors without needing to write any code. Additional information on using Connect is available <a href="/documentation.html#connect">here</a>.
+ <p>
+ Those who want to implement custom connectors can see the <a href="/{{version}}/javadoc/index.html?org/apache/kafka/connect" title="Kafka {{dotVersion}} Javadoc">javadoc</a>.
+ <p>
+
+ <h3><a id="adminapi" href="#adminapi">2.5 AdminClient API</a></h3>
+
+ The AdminClient API supports managing and inspecting topics, brokers, acls, and other Kafka objects.
+ <p>
+ To use the AdminClient API, add the following Maven dependency:
+ <pre class="brush: xml;">
+ <dependency>
+ <groupId>org.apache.kafka</groupId>
+ <artifactId>kafka-clients</artifactId>
+ <version>{{fullDotVersion}}</version>
+ </dependency>
+ </pre>
+ For more information about the AdminClient APIs, see the <a href="/{{version}}/javadoc/index.html?org/apache/kafka/clients/admin/AdminClient.html" title="Kafka {{dotVersion}} Javadoc">javadoc</a>.
+ <p>
+
+ <h3><a id="legacyapis" href="#legacyapis">2.6 Legacy APIs</a></h3>
+
+ <p>
+ A more limited legacy producer and consumer api is also included in Kafka. These old Scala APIs are deprecated and only still available for compatibility purposes. Information on them can be found here <a href="/081/documentation.html#producerapi" title="Kafka 0.8.1 Docs">
+ here</a>.
+ </p>
+</script>
+
+<div class="p-api"></div>
diff --git a/11/configuration.html b/11/configuration.html
new file mode 100644
index 0000000..df58ba7
--- /dev/null
+++ b/11/configuration.html
@@ -0,0 +1,418 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<script id="configuration-template" type="text/x-handlebars-template">
+ Kafka uses key-value pairs in the <a href="http://en.wikipedia.org/wiki/.properties">property file format</a> for configuration. These values can be supplied either from a file or programmatically.
+
+ <h3><a id="brokerconfigs" href="#brokerconfigs">3.1 Broker Configs</a></h3>
+
+ The essential configurations are the following:
+ <ul>
+ <li><code>broker.id</code>
+ <li><code>log.dirs</code>
+ <li><code>zookeeper.connect</code>
+ </ul>
+
+ Topic-level configurations and defaults are discussed in more detail <a href="#topicconfigs">below</a>.
+
+ <!--#include virtual="generated/kafka_config.html" -->
+
+ <p>More details about broker configuration can be found in the scala class <code>kafka.server.KafkaConfig</code>.</p>
+
+ <h4><a id="dynamicbrokerconfigs" href="#dynamicbrokerconfigs">3.1.1 Updating Broker Configs</a></h4>
+ From Kafka version 1.1 onwards, some of the broker configs can be updated without restarting the broker. See the
+ <code>Dynamic Update Mode</code> column in <a href="#brokerconfigs">Broker Configs</a> for the update mode of each broker config.
+ <ul>
+ <li><code>read-only</code>: Requires a broker restart for update</li>
+ <li><code>per-broker</code>: May be updated dynamically for each broker</li>
+ <li><code>cluster-wide</code>: May be updated dynamically as a cluster-wide default. May also be updated as a per-broker value for testing.</li>
+ </ul>
+
+ To alter the current broker configs for broker id 0 (for example, the number of log cleaner threads):
+ <pre class="brush: bash;">
+ > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2
+ </pre>
+
+ To describe the current dynamic broker configs for broker id 0:
+ <pre class="brush: bash;">
+ > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --describe
+ </pre>
+
+ To delete a config override and revert to the statically configured or default value for broker id 0 (for example,
+ the number of log cleaner threads):
+ <pre class="brush: bash;">
+ > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --delete-config log.cleaner.threads
+ </pre>
+
+ Some configs may be configured as a cluster-wide default to maintain consistent values across the whole cluster. All brokers
+ in the cluster will process the cluster default update. For example, to update log cleaner threads on all brokers:
+ <pre class="brush: bash;">
+ > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --alter --add-config log.cleaner.threads=2
+ </pre>
+
+ To describe the currently configured dynamic cluster-wide default configs:
+ <pre class="brush: bash;">
+ > bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-default --describe
+ </pre>
+
+ All configs that are configurable at cluster level may also be configured at per-broker level (e.g. for testing).
+ If a config value is defined at different levels, the following order of precedence is used:
+ <ul>
+ <li>Dynamic per-broker config stored in ZooKeeper</li>
+ <li>Dynamic cluster-wide default config stored in ZooKeeper</li>
+ <li>Static broker config from <code>server.properties</code></li>
+ <li>Kafka default, see <a href="#brokerconfigs">broker configs</a></li>
+ </ul>
+
+ <h5>Updating Password Configs Dynamically</h5>
+ <p>Password config values that are dynamically updated are encrypted before storing in ZooKeeper. The broker config
+ <code>password.encoder.secret</code> must be configured in <code>server.properties</code> to enable dynamic update
+ of password configs. The secret may be different on different brokers.</p>
+ <p>The secret used for password encoding may be rotated with a rolling restart of brokers. The old secret used for encoding
+ passwords currently in ZooKeeper must be provided in the static broker config <code>password.encoder.old.secret</code> and
+ the new secret must be provided in <code>password.encoder.secret</code>. All dynamic password configs stored in ZooKeeper
+ will be re-encoded with the new secret when the broker starts up.</p>
+ <p>In Kafka 1.1.x, all dynamically updated password configs must be provided in every alter request when updating configs
+ using <code>kafka-configs.sh</code> even if the password config is not being altered. This constraint will be removed in
+ a future release.</p>
+
+ <h5>Updating SSL Keystore of an Existing Listener</h5>
+ Brokers may be configured with SSL keystores with short validity periods to reduce the risk of compromised certificates.
+ Keystores may be updated dynamically without restarting the broker. The config name must be prefixed with the listener prefix
+ <code>listener.name.{listenerName}.</code> so that only the keystore config of a specific listener is updated.
+ The following configs may be updated in a single alter request at per-broker level:
+ <ul>
+ <li><code>ssl.keystore.type</code></li>
+ <li><code>ssl.keystore.location</code></li>
+ <li><code>ssl.keystore.password</code></li>
+ <li><code>ssl.key.password</code></li>
+ </ul>
+ If the listener is the inter-broker listener, the update is allowed only if the new keystore is trusted by the truststore
+ configured for that listener. For other listeners, no trust validation is performed on the keystore by the broker. Certificates
+ must be signed by the same certificate authority that signed the old certificate to avoid any client authentication failures.
+
+ <h5>Updating Default Topic Configuration</h5>
+ Default topic configuration options used by brokers may be updated without broker restart. The configs are applied to topics
+ without a topic config override for the equivalent per-topic config. One or more of these configs may be overridden at
+ cluster-default level used by all brokers.
+ <ul>
+ <li><code>log.segment.bytes</code></li>
+ <li><code>log.roll.ms</code></li>
+ <li><code>log.roll.hours</code></li>
+ <li><code>log.roll.jitter.ms</code></li>
+ <li><code>log.roll.jitter.hours</code></li>
+ <li><code>log.index.size.max.bytes</code></li>
+ <li><code>log.flush.interval.messages</code></li>
+ <li><code>log.flush.interval.ms</code></li>
+ <li><code>log.retention.bytes</code></li>
+ <li><code>log.retention.ms</code></li>
+ <li><code>log.retention.minutes</code></li>
+ <li><code>log.retention.hours</code></li>
+ <li><code>log.index.interval.bytes</code></li>
+ <li><code>log.cleaner.delete.retention.ms</code></li>
+ <li><code>log.cleaner.min.compaction.lag.ms</code></li>
+ <li><code>log.cleaner.min.cleanable.ratio</code></li>
+ <li><code>log.cleanup.policy</code></li>
+ <li><code>log.segment.delete.delay.ms</code></li>
+ <li><code>unclean.leader.election.enable</code></li>
+ <li><code>min.insync.replicas</code></li>
+ <li><code>max.message.bytes</code></li>
+ <li><code>compression.type</code></li>
+ <li><code>log.preallocate</code></li>
+ <li><code>log.message.timestamp.type</code></li>
+ <li><code>log.message.timestamp.difference.max.ms</code></li>
+ </ul>
+
+ In Kafka version 1.1.x, changes to <code>unclean.leader.election.enable</code> take effect only when a new controller is elected.
+ Controller re-election may be forced by running:
+
+ <pre class="brush: bash;">
+ > bin/zookeeper-shell.sh localhost
+ rmr /controller
+ </pre>
+
+ <h5>Updating Log Cleaner Configs</h5>
+ Log cleaner configs may be updated dynamically at cluster-default level used by all brokers. The changes take effect
+ on the next iteration of log cleaning. One or more of these configs may be updated:
+ <ul>
+ <li><code>log.cleaner.threads</code></li>
+ <li><code>log.cleaner.io.max.bytes.per.second</code></li>
+ <li><code>log.cleaner.dedupe.buffer.size</code></li>
+ <li><code>log.cleaner.io.buffer.size</code></li>
+ <li><code>log.cleaner.io.buffer.load.factor</code></li>
+ <li><code>log.cleaner.backoff.ms</code></li>
+ </ul>
+
+ <h5>Updating Thread Configs</h5>
+ The size of various thread pools used by the broker may be updated dynamically at cluster-default level used by all brokers.
+ Updates are restricted to the range <code>currentSize / 2</code> to <code>currentSize * 2</code> to ensure that config updates are
+ handled gracefully.
+ <ul>
+ <li><code>num.network.threads</code></li>
+ <li><code>num.io.threads</code></li>
+ <li><code>num.replica.fetchers</code></li>
+ <li><code>num.recovery.threads.per.data.dir</code></li>
+ <li><code>log.cleaner.threads</code></li>
+ <li><code>background.threads</code></li>
+ </ul>
+
+ <h5>Adding and Removing Listeners</h5>
+ <p>Listeners may be added or removed dynamically. When a new listener is added, security configs of the listener must be provided
+ as listener configs with the listener prefix <code>listener.name.{listenerName}.</code>. If the new listener uses SASL,
+ the JAAS configuration of the listener must be provided using the JAAS configuration property <code>sasl.jaas.config</code>
+ with the listener and mechanism prefix. See <a href="#security_jaas_broker">JAAS configuration for Kafka brokers</a> for details.</p>
+
+ <p>In Kafka version 1.1.x, the listener used by the inter-broker listener may not be updated dynamically. To update the inter-broker
+ listener to a new listener, the new listener may be added on all brokers without restarting the broker. A rolling restart is then
+ required to update <code>inter.broker.listener.name</code>.</p>
+
+ In addition to all the security configs of new listeners, the following configs may be updated dynamically at per-broker level:
+ <ul>
+ <li><code>listeners</code></li>
+ <li><code>advertised.listeners</code></li>
+ <li><code>listener.security.protocol.map</code></li>
+ </ul>
+ Inter-broker listener must be configured using the static broker configuration <code>inter.broker.listener.name</code>
+ or <code>inter.broker.security.protocol</code>.
+
+ <h3><a id="topicconfigs" href="#topicconfigs">3.2 Topic-Level Configs</a></h3>
+
+ Configurations pertinent to topics have both a server default as well an optional per-topic override. If no per-topic configuration is given the server default is used. The override can be set at topic creation time by giving one or more <code>--config</code> options. This example creates a topic named <i>my-topic</i> with a custom max message size and flush rate:
+ <pre class="brush: bash;">
+ > bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic my-topic --partitions 1
+ --replication-factor 1 --config max.message.bytes=64000 --config flush.messages=1
+ </pre>
+ Overrides can also be changed or set later using the alter configs command. This example updates the max message size for <i>my-topic</i>:
+ <pre class="brush: bash;">
+ > bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name my-topic
+ --alter --add-config max.message.bytes=128000
+ </pre>
+
+ To check overrides set on the topic you can do
+ <pre class="brush: bash;">
+ > bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name my-topic --describe
+ </pre>
+
+ To remove an override you can do
+ <pre class="brush: bash;">
+ > bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name my-topic --alter --delete-config max.message.bytes
+ </pre>
+
+ The following are the topic-level configurations. The server's default configuration for this property is given under the Server Default Property heading. A given server default config value only applies to a topic if it does not have an explicit topic config override.
+
+ <!--#include virtual="generated/topic_config.html" -->
+
+ <h3><a id="producerconfigs" href="#producerconfigs">3.3 Producer Configs</a></h3>
+
+ Below is the configuration of the Java producer:
+ <!--#include virtual="generated/producer_config.html" -->
+
+ <p>
+ For those interested in the legacy Scala producer configs, information can be found <a href="http://kafka.apache.org/082/documentation.html#producerconfigs">
+ here</a>.
+ </p>
+
+ <h3><a id="consumerconfigs" href="#consumerconfigs">3.4 Consumer Configs</a></h3>
+
+ In 0.9.0.0 we introduced the new Java consumer as a replacement for the older Scala-based simple and high-level consumers.
+ The configs for both new and old consumers are described below.
+
+ <h4><a id="newconsumerconfigs" href="#newconsumerconfigs">3.4.1 New Consumer Configs</a></h4>
+ Below is the configuration for the new consumer:
+ <!--#include virtual="generated/consumer_config.html" -->
+
+ <h4><a id="oldconsumerconfigs" href="#oldconsumerconfigs">3.4.2 Old Consumer Configs</a></h4>
+
+ The essential old consumer configurations are the following:
+ <ul>
+ <li><code>group.id</code>
+ <li><code>zookeeper.connect</code>
+ </ul>
+
+ <table class="data-table">
+ <tbody><tr>
+ <th>Property</th>
+ <th>Default</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td>group.id</td>
+ <td colspan="1"></td>
+ <td>A string that uniquely identifies the group of consumer processes to which this consumer belongs. By setting the same group id multiple processes indicate that they are all part of the same consumer group.</td>
+ </tr>
+ <tr>
+ <td>zookeeper.connect</td>
+ <td colspan="1"></td>
+ <td>Specifies the ZooKeeper connection string in the form <code>hostname:port</code> where host and port are the host and port of a ZooKeeper server. To allow connecting through other ZooKeeper nodes when that ZooKeeper machine is down you can also specify multiple hosts in the form <code>hostname1:port1,hostname2:port2,hostname3:port3</code>.
+ <p>
+ The server may also have a ZooKeeper chroot path as part of its ZooKeeper connection string which puts its data under some path in the global ZooKeeper namespace. If so the consumer should use the same chroot path in its connection string. For example to give a chroot path of <code>/chroot/path</code> you would give the connection string as <code>hostname1:port1,hostname2:port2,hostname3:port3/chroot/path</code>.</td>
+ </tr>
+ <tr>
+ <td>consumer.id</td>
+ <td colspan="1">null</td>
+ <td>
+ <p>Generated automatically if not set.</p>
+ </td>
+ </tr>
+ <tr>
+ <td>socket.timeout.ms</td>
+ <td colspan="1">30 * 1000</td>
+ <td>The socket timeout for network requests. The actual timeout set will be fetch.wait.max.ms + socket.timeout.ms.</td>
+ </tr>
+ <tr>
+ <td>socket.receive.buffer.bytes</td>
+ <td colspan="1">64 * 1024</td>
+ <td>The socket receive buffer for network requests</td>
+ </tr>
+ <tr>
+ <td>fetch.message.max.bytes</td>
+ <td nowrap>1024 * 1024</td>
+ <td>The number of bytes of messages to attempt to fetch for each topic-partition in each fetch request. These bytes will be read into memory for each partition, so this helps control the memory used by the consumer. The fetch request size must be at least as large as the maximum message size the server allows or else it is possible for the producer to send messages larger than the consumer can fetch.</td>
+ </tr>
+ <tr>
+ <td>num.consumer.fetchers</td>
+ <td colspan="1">1</td>
+ <td>The number fetcher threads used to fetch data.</td>
+ </tr>
+ <tr>
+ <td>auto.commit.enable</td>
+ <td colspan="1">true</td>
+ <td>If true, periodically commit to ZooKeeper the offset of messages already fetched by the consumer. This committed offset will be used when the process fails as the position from which the new consumer will begin.</td>
+ </tr>
+ <tr>
+ <td>auto.commit.interval.ms</td>
+ <td colspan="1">60 * 1000</td>
+ <td>The frequency in ms that the consumer offsets are committed to zookeeper.</td>
+ </tr>
+ <tr>
+ <td>queued.max.message.chunks</td>
+ <td colspan="1">2</td>
+ <td>Max number of message chunks buffered for consumption. Each chunk can be up to fetch.message.max.bytes.</td>
+ </tr>
+ <tr>
+ <td>rebalance.max.retries</td>
+ <td colspan="1">4</td>
+ <td>When a new consumer joins a consumer group the set of consumers attempt to "rebalance" the load to assign partitions to each consumer. If the set of consumers changes while this assignment is taking place the rebalance will fail and retry. This setting controls the maximum number of attempts before giving up.</td>
+ </tr>
+ <tr>
+ <td>fetch.min.bytes</td>
+ <td colspan="1">1</td>
+ <td>The minimum amount of data the server should return for a fetch request. If insufficient data is available the request will wait for that much data to accumulate before answering the request.</td>
+ </tr>
+ <tr>
+ <td>fetch.wait.max.ms</td>
+ <td colspan="1">100</td>
+ <td>The maximum amount of time the server will block before answering the fetch request if there isn't sufficient data to immediately satisfy fetch.min.bytes</td>
+ </tr>
+ <tr>
+ <td>rebalance.backoff.ms</td>
+ <td>2000</td>
+ <td>Backoff time between retries during rebalance. If not set explicitly, the value in zookeeper.sync.time.ms is used.
+ </td>
+ </tr>
+ <tr>
+ <td>refresh.leader.backoff.ms</td>
+ <td colspan="1">200</td>
+ <td>Backoff time to wait before trying to determine the leader of a partition that has just lost its leader.</td>
+ </tr>
+ <tr>
+ <td>auto.offset.reset</td>
+ <td colspan="1">largest</td>
+ <td>
+ <p>What to do when there is no initial offset in ZooKeeper or if an offset is out of range:<br/>* smallest : automatically reset the offset to the smallest offset<br/>* largest : automatically reset the offset to the largest offset<br/>* anything else: throw exception to the consumer</p>
+ </td>
+ </tr>
+ <tr>
+ <td>consumer.timeout.ms</td>
+ <td colspan="1">-1</td>
+ <td>Throw a timeout exception to the consumer if no message is available for consumption after the specified interval</td>
+ </tr>
+ <tr>
+ <td>exclude.internal.topics</td>
+ <td colspan="1">true</td>
+ <td>Whether messages from internal topics (such as offsets) should be exposed to the consumer.</td>
+ </tr>
+ <tr>
+ <td>client.id</td>
+ <td colspan="1">group id value</td>
+ <td>The client id is a user-specified string sent in each request to help trace calls. It should logically identify the application making the request.</td>
+ </tr>
+ <tr>
+ <td>zookeeper.session.timeout.ms </td>
+ <td colspan="1">6000</td>
+ <td>ZooKeeper session timeout. If the consumer fails to heartbeat to ZooKeeper for this period of time it is considered dead and a rebalance will occur.</td>
+ </tr>
+ <tr>
+ <td>zookeeper.connection.timeout.ms</td>
+ <td colspan="1">6000</td>
+ <td>The max time that the client waits while establishing a connection to zookeeper.</td>
+ </tr>
+ <tr>
+ <td>zookeeper.sync.time.ms </td>
+ <td colspan="1">2000</td>
+ <td>How far a ZK follower can be behind a ZK leader</td>
+ </tr>
+ <tr>
+ <td>offsets.storage</td>
+ <td colspan="1">zookeeper</td>
+ <td>Select where offsets should be stored (zookeeper or kafka).</td>
+ </tr>
+ <tr>
+ <td>offsets.channel.backoff.ms</td>
+ <td colspan="1">1000</td>
+ <td>The backoff period when reconnecting the offsets channel or retrying failed offset fetch/commit requests.</td>
+ </tr>
+ <tr>
+ <td>offsets.channel.socket.timeout.ms</td>
+ <td colspan="1">10000</td>
+ <td>Socket timeout when reading responses for offset fetch/commit requests. This timeout is also used for ConsumerMetadata requests that are used to query for the offset manager.</td>
+ </tr>
+ <tr>
+ <td>offsets.commit.max.retries</td>
+ <td colspan="1">5</td>
+ <td>Retry the offset commit up to this many times on failure. This retry count only applies to offset commits during shut-down. It does not apply to commits originating from the auto-commit thread. It also does not apply to attempts to query for the offset coordinator before committing offsets. i.e., if a consumer metadata request fails for any reason, it will be retried and that retry does not count toward this limit.</td>
+ </tr>
+ <tr>
+ <td>dual.commit.enabled</td>
+ <td colspan="1">true</td>
+ <td>If you are using "kafka" as offsets.storage, you can dual commit offsets to ZooKeeper (in addition to Kafka). This is required during migration from zookeeper-based offset storage to kafka-based offset storage. With respect to any given consumer group, it is safe to turn this off after all instances within that group have been migrated to the new version that commits offsets to the broker (instead of directly to ZooKeeper).</td>
+ </tr>
+ <tr>
+ <td>partition.assignment.strategy</td>
+ <td colspan="1">range</td>
+ <td><p>Select between the "range" or "roundrobin" strategy for assigning partitions to consumer streams.<p>The round-robin partition assignor lays out all the available partitions and all the available consumer threads. It then proceeds to do a round-robin assignment from partition to consumer thread. If the subscriptions of all consumer instances are identical, then the partitions will be uniformly distributed. (i.e., the partition ownership counts will be within a delta of exac [...]
+ </tr>
+ </tbody>
+ </table>
+
+
+ <p>More details about consumer configuration can be found in the scala class <code>kafka.consumer.ConsumerConfig</code>.</p>
+
+ <h3><a id="connectconfigs" href="#connectconfigs">3.5 Kafka Connect Configs</a></h3>
+ Below is the configuration of the Kafka Connect framework.
+ <!--#include virtual="generated/connect_config.html" -->
+
+ <h3><a id="streamsconfigs" href="#streamsconfigs">3.6 Kafka Streams Configs</a></h3>
+ Below is the configuration of the Kafka Streams client library.
+ <!--#include virtual="generated/streams_config.html" -->
+
+ <h3><a id="adminclientconfigs" href="#adminclientconfigs">3.7 AdminClient Configs</a></h3>
+ Below is the configuration of the Kafka Admin client library.
+ <!--#include virtual="generated/admin_client_config.html" -->
+</script>
+
+<div class="p-configuration"></div>
diff --git a/11/connect.html b/11/connect.html
new file mode 100644
index 0000000..d5e2fc9
--- /dev/null
+++ b/11/connect.html
@@ -0,0 +1,551 @@
+<!--~
+ ~ Licensed to the Apache Software Foundation (ASF) under one or more
+ ~ contributor license agreements. See the NOTICE file distributed with
+ ~ this work for additional information regarding copyright ownership.
+ ~ The ASF licenses this file to You under the Apache License, Version 2.0
+ ~ (the "License"); you may not use this file except in compliance with
+ ~ the License. You may obtain a copy of the License at
+ ~
+ ~ http://www.apache.org/licenses/LICENSE-2.0
+ ~
+ ~ Unless required by applicable law or agreed to in writing, software
+ ~ distributed under the License is distributed on an "AS IS" BASIS,
+ ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ ~ See the License for the specific language governing permissions and
+ ~ limitations under the License.
+ ~-->
+
+<script id="connect-template" type="text/x-handlebars-template">
+ <h3><a id="connect_overview" href="#connect_overview">8.1 Overview</a></h3>
+
+ <p>Kafka Connect is a tool for scalably and reliably streaming data between Apache Kafka and other systems. It makes it simple to quickly define <i>connectors</i> that move large collections of data into and out of Kafka. Kafka Connect can ingest entire databases or collect metrics from all your application servers into Kafka topics, making the data available for stream processing with low latency. An export job can deliver data from Kafka topics into secondary storage and query syst [...]
+
+ <p>Kafka Connect features include:</p>
+ <ul>
+ <li><b>A common framework for Kafka connectors</b> - Kafka Connect standardizes integration of other data systems with Kafka, simplifying connector development, deployment, and management</li>
+ <li><b>Distributed and standalone modes</b> - scale up to a large, centrally managed service supporting an entire organization or scale down to development, testing, and small production deployments</li>
+ <li><b>REST interface</b> - submit and manage connectors to your Kafka Connect cluster via an easy to use REST API</li>
+ <li><b>Automatic offset management</b> - with just a little information from connectors, Kafka Connect can manage the offset commit process automatically so connector developers do not need to worry about this error prone part of connector development</li>
+ <li><b>Distributed and scalable by default</b> - Kafka Connect builds on the existing group management protocol. More workers can be added to scale up a Kafka Connect cluster.</li>
+ <li><b>Streaming/batch integration</b> - leveraging Kafka's existing capabilities, Kafka Connect is an ideal solution for bridging streaming and batch data systems</li>
+ </ul>
+
+ <h3><a id="connect_user" href="#connect_user">8.2 User Guide</a></h3>
+
+ <p>The quickstart provides a brief example of how to run a standalone version of Kafka Connect. This section describes how to configure, run, and manage Kafka Connect in more detail.</p>
+
+ <h4><a id="connect_running" href="#connect_running">Running Kafka Connect</a></h4>
+
+ <p>Kafka Connect currently supports two modes of execution: standalone (single process) and distributed.</p>
+
+ <p>In standalone mode all work is performed in a single process. This configuration is simpler to setup and get started with and may be useful in situations where only one worker makes sense (e.g. collecting log files), but it does not benefit from some of the features of Kafka Connect such as fault tolerance. You can start a standalone process with the following command:</p>
+
+ <pre class="brush: bash;">
+ > bin/connect-standalone.sh config/connect-standalone.properties connector1.properties [connector2.properties ...]
+ </pre>
+
+ <p>The first parameter is the configuration for the worker. This includes settings such as the Kafka connection parameters, serialization format, and how frequently to commit offsets. The provided example should work well with a local cluster running with the default configuration provided by <code>config/server.properties</code>. It will require tweaking to use with a different configuration or production deployment. All workers (both standalone and distributed) require a few configs:</p>
+ <ul>
+ <li><code>bootstrap.servers</code> - List of Kafka servers used to bootstrap connections to Kafka</li>
+ <li><code>key.converter</code> - Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the keys in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro.</li>
+ <li><code>value.converter</code> - Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the values in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro.</li>
+ </ul>
+
+ <p>The important configuration options specific to standalone mode are:</p>
+ <ul>
+ <li><code>offset.storage.file.filename</code> - File to store offset data in</li>
+ </ul>
+
+ <p>The parameters that are configured here are intended for producers and consumers used by Kafka Connect to access the configuration, offset and status topics. For configuration of Kafka source and Kafka sink tasks, the same parameters can be used but need to be prefixed with <code>consumer.</code> and <code>producer.</code> respectively. The only parameter that is inherited from the worker configuration is <code>bootstrap.servers</code>, which in most cases will be sufficient, sinc [...]
+
+ <p>The remaining parameters are connector configuration files. You may include as many as you want, but all will execute within the same process (on different threads).</p>
+
+ <p>Distributed mode handles automatic balancing of work, allows you to scale up (or down) dynamically, and offers fault tolerance both in the active tasks and for configuration and offset commit data. Execution is very similar to standalone mode:</p>
+
+ <pre class="brush: bash;">
+ > bin/connect-distributed.sh config/connect-distributed.properties
+ </pre>
+
+ <p>The difference is in the class which is started and the configuration parameters which change how the Kafka Connect process decides where to store configurations, how to assign work, and where to store offsets and task statues. In the distributed mode, Kafka Connect stores the offsets, configs and task statuses in Kafka topics. It is recommended to manually create the topics for offset, configs and statuses in order to achieve the desired the number of partitions and replication f [...]
+
+ <p>In particular, the following configuration parameters, in addition to the common settings mentioned above, are critical to set before starting your cluster:</p>
+ <ul>
+ <li><code>group.id</code> (default <code>connect-cluster</code>) - unique name for the cluster, used in forming the Connect cluster group; note that this <b>must not conflict</b> with consumer group IDs</li>
+ <li><code>config.storage.topic</code> (default <code>connect-configs</code>) - topic to use for storing connector and task configurations; note that this should be a single partition, highly replicated, compacted topic. You may need to manually create the topic to ensure the correct configuration as auto created topics may have multiple partitions or be automatically configured for deletion rather than compaction</li>
+ <li><code>offset.storage.topic</code> (default <code>connect-offsets</code>) - topic to use for storing offsets; this topic should have many partitions, be replicated, and be configured for compaction</li>
+ <li><code>status.storage.topic</code> (default <code>connect-status</code>) - topic to use for storing statuses; this topic can have multiple partitions, and should be replicated and configured for compaction</li>
+ </ul>
+
+ <p>Note that in distributed mode the connector configurations are not passed on the command line. Instead, use the REST API described below to create, modify, and destroy connectors.</p>
+
+
+ <h4><a id="connect_configuring" href="#connect_configuring">Configuring Connectors</a></h4>
+
+ <p>Connector configurations are simple key-value mappings. For standalone mode these are defined in a properties file and passed to the Connect process on the command line. In distributed mode, they will be included in the JSON payload for the request that creates (or modifies) the connector.</p>
+
+ <p>Most configurations are connector dependent, so they can't be outlined here. However, there are a few common options:</p>
+
+ <ul>
+ <li><code>name</code> - Unique name for the connector. Attempting to register again with the same name will fail.</li>
+ <li><code>connector.class</code> - The Java class for the connector</li>
+ <li><code>tasks.max</code> - The maximum number of tasks that should be created for this connector. The connector may create fewer tasks if it cannot achieve this level of parallelism.</li>
+ <li><code>key.converter</code> - (optional) Override the default key converter set by the worker.</li>
+ <li><code>value.converter</code> - (optional) Override the default value converter set by the worker.</li>
+ </ul>
+
+ <p>The <code>connector.class</code> config supports several formats: the full name or alias of the class for this connector. If the connector is org.apache.kafka.connect.file.FileStreamSinkConnector, you can either specify this full name or use FileStreamSink or FileStreamSinkConnector to make the configuration a bit shorter.</p>
+
+ <p>Sink connectors also have a few additional options to control their input. Each sink connector must set one of the following:</p>
+ <ul>
+ <li><code>topics</code> - A comma-separated list of topics to use as input for this connector</li>
+ <li><code>topics.regex</code> - A Java regular expression of topics to use as input for this connector</li>
+ </ul>
+
+ <p>For any other options, you should consult the documentation for the connector.</p>
+
+ <h4><a id="connect_transforms" href="#connect_transforms">Transformations</a></h4>
+
+ <p>Connectors can be configured with transformations to make lightweight message-at-a-time modifications. They can be convenient for data massaging and event routing.</p>
+
+ <p>A transformation chain can be specified in the connector configuration.</p>
+
+ <ul>
+ <li><code>transforms</code> - List of aliases for the transformation, specifying the order in which the transformations will be applied.</li>
+ <li><code>transforms.$alias.type</code> - Fully qualified class name for the transformation.</li>
+ <li><code>transforms.$alias.$transformationSpecificConfig</code> Configuration properties for the transformation</li>
+ </ul>
+
+ <p>For example, lets take the built-in file source connector and use a transformation to add a static field.</p>
+
+ <p>Throughout the example we'll use schemaless JSON data format. To use schemaless format, we changed the following two lines in <code>connect-standalone.properties</code> from true to false:</p>
+
+ <pre class="brush: text;">
+ key.converter.schemas.enable
+ value.converter.schemas.enable
+ </pre>
+
+ <p>The file source connector reads each line as a String. We will wrap each line in a Map and then add a second field to identify the origin of the event. To do this, we use two transformations:</p>
+ <ul>
+ <li><b>HoistField</b> to place the input line inside a Map</li>
+ <li><b>InsertField</b> to add the static field. In this example we'll indicate that the record came from a file connector</li>
+ </ul>
+
+ <p>After adding the transformations, <code>connect-file-source.properties</code> file looks as following:</p>
+
+ <pre class="brush: text;">
+ name=local-file-source
+ connector.class=FileStreamSource
+ tasks.max=1
+ file=test.txt
+ topic=connect-test
+ transforms=MakeMap, InsertSource
+ transforms.MakeMap.type=org.apache.kafka.connect.transforms.HoistField$Value
+ transforms.MakeMap.field=line
+ transforms.InsertSource.type=org.apache.kafka.connect.transforms.InsertField$Value
+ transforms.InsertSource.static.field=data_source
+ transforms.InsertSource.static.value=test-file-source
+ </pre>
+
+ <p>All the lines starting with <code>transforms</code> were added for the transformations. You can see the two transformations we created: "InsertSource" and "MakeMap" are aliases that we chose to give the transformations. The transformation types are based on the list of built-in transformations you can see below. Each transformation type has additional configuration: HoistField requires a configuration called "field", which is the name of the field in the map that will include the [...]
+
+ <p>When we ran the file source connector on my sample file without the transformations, and then read them using <code>kafka-console-consumer.sh</code>, the results were:</p>
+
+ <pre class="brush: text;">
+ "foo"
+ "bar"
+ "hello world"
+ </pre>
+
+ <p>We then create a new file connector, this time after adding the transformations to the configuration file. This time, the results will be:</p>
+
+ <pre class="brush: json;">
+ {"line":"foo","data_source":"test-file-source"}
+ {"line":"bar","data_source":"test-file-source"}
+ {"line":"hello world","data_source":"test-file-source"}
+ </pre>
+
+ <p>You can see that the lines we've read are now part of a JSON map, and there is an extra field with the static value we specified. This is just one example of what you can do with transformations.</p>
+
+ <p>Several widely-applicable data and routing transformations are included with Kafka Connect:</p>
+
+ <ul>
+ <li>InsertField - Add a field using either static data or record metadata</li>
+ <li>ReplaceField - Filter or rename fields</li>
+ <li>MaskField - Replace field with valid null value for the type (0, empty string, etc)</li>
+ <li>ValueToKey</li>
+ <li>HoistField - Wrap the entire event as a single field inside a Struct or a Map</li>
+ <li>ExtractField - Extract a specific field from Struct and Map and include only this field in results</li>
+ <li>SetSchemaMetadata - modify the schema name or version</li>
+ <li>TimestampRouter - Modify the topic of a record based on original topic and timestamp. Useful when using a sink that needs to write to different tables or indexes based on timestamps</li>
+ <li>RegexRouter - modify the topic of a record based on original topic, replacement string and a regular expression</li>
+ </ul>
+
+ <p>Details on how to configure each transformation are listed below:</p>
+
+
+ <!--#include virtual="generated/connect_transforms.html" -->
+
+ <h4><a id="connect_rest" href="#connect_rest">REST API</a></h4>
+
+ <p>Since Kafka Connect is intended to be run as a service, it also provides a REST API for managing connectors. The REST API server can be configured using the <code>listeners</code> configuration option.
+ This field should contain a list of listeners in the following format: <code>protocol://host:port,protocol2://host2:port2</code>. Currently supported protocols are <code>http</code> and <code>https</code>.
+ For example:</p>
+
+ <pre class="brush: text;">
+ listeners=http://localhost:8080,https://localhost:8443
+ </pre>
+
+ <p>By default, if no <code>listeners</code> are specified, the REST server runs on port 8083 using the HTTP protocol. When using HTTPS, the configuration has to include the SSL configuration.
+ By default, it will use the <code>ssl.*</code> settings. In case it is needed to use different configuration for the REST API than for connecting to Kafka brokers, the fields can be prefixed with <code>listeners.https</code>.
+ When using the prefix, only the prefixed options will be used and the <code>ssl.*</code> options without the prefix will be ignored. Following fields can be used to configure HTTPS for the REST API:</p>
+
+ <ul>
+ <li><code>ssl.keystore.location</code></li>
+ <li><code>ssl.keystore.password</code></li>
+ <li><code>ssl.keystore.type</code></li>
+ <li><code>ssl.key.password</code></li>
+ <li><code>ssl.truststore.location</code></li>
+ <li><code>ssl.truststore.password</code></li>
+ <li><code>ssl.truststore.type</code></li>
+ <li><code>ssl.enabled.protocols</code></li>
+ <li><code>ssl.provider</code></li>
+ <li><code>ssl.protocol</code></li>
+ <li><code>ssl.cipher.suites</code></li>
+ <li><code>ssl.keymanager.algorithm</code></li>
+ <li><code>ssl.secure.random.implementation</code></li>
+ <li><code>ssl.trustmanager.algorithm</code></li>
+ <li><code>ssl.endpoint.identification.algorithm</code></li>
+ <li><code>ssl.client.auth</code></li>
+ </ul>
+
+ <p>The REST API is used not only by users to monitor / manage Kafka Connect. It is also used for the Kafka Connect cross-cluster communication. Requests received on the follower nodes REST API will be forwarded to the leader node REST API.
+ In case the URI under which is given host reachable is different from the URI which it listens on, the configuration options <code>rest.advertised.host.name</code>, <code>rest.advertised.port</code> and <code>rest.advertised.listener</code>
+ can be used to change the URI which will be used by the follower nodes to connect with the leader. When using both HTTP and HTTPS listeners, the <code>rest.advertised.listener</code> option can be also used to define which listener
+ will be used for the cross-cluster communication. When using HTTPS for communication between nodes, the same <code>ssl.*</code> or <code>listeners.https</code> options will be used to configure the HTTPS client.</p>
+
+ <p>The following are the currently supported REST API endpoints:</p>
+
+ <ul>
+ <li><code>GET /connectors</code> - return a list of active connectors</li>
+ <li><code>POST /connectors</code> - create a new connector; the request body should be a JSON object containing a string <code>name</code> field and an object <code>config</code> field with the connector configuration parameters</li>
+ <li><code>GET /connectors/{name}</code> - get information about a specific connector</li>
+ <li><code>GET /connectors/{name}/config</code> - get the configuration parameters for a specific connector</li>
+ <li><code>PUT /connectors/{name}/config</code> - update the configuration parameters for a specific connector</li>
+ <li><code>GET /connectors/{name}/status</code> - get current status of the connector, including if it is running, failed, paused, etc., which worker it is assigned to, error information if it has failed, and the state of all its tasks</li>
+ <li><code>GET /connectors/{name}/tasks</code> - get a list of tasks currently running for a connector</li>
+ <li><code>GET /connectors/{name}/tasks/{taskid}/status</code> - get current status of the task, including if it is running, failed, paused, etc., which worker it is assigned to, and error information if it has failed</li>
+ <li><code>PUT /connectors/{name}/pause</code> - pause the connector and its tasks, which stops message processing until the connector is resumed</li>
+ <li><code>PUT /connectors/{name}/resume</code> - resume a paused connector (or do nothing if the connector is not paused)</li>
+ <li><code>POST /connectors/{name}/restart</code> - restart a connector (typically because it has failed)</li>
+ <li><code>POST /connectors/{name}/tasks/{taskId}/restart</code> - restart an individual task (typically because it has failed)</li>
+ <li><code>DELETE /connectors/{name}</code> - delete a connector, halting all tasks and deleting its configuration</li>
+ </ul>
+
+ <p>Kafka Connect also provides a REST API for getting information about connector plugins:</p>
+
+ <ul>
+ <li><code>GET /connector-plugins</code>- return a list of connector plugins installed in the Kafka Connect cluster. Note that the API only checks for connectors on the worker that handles the request, which means you may see inconsistent results, especially during a rolling upgrade if you add new connector jars</li>
+ <li><code>PUT /connector-plugins/{connector-type}/config/validate</code> - validate the provided configuration values against the configuration definition. This API performs per config validation, returns suggested values and error messages during validation.</li>
+ </ul>
+
+ <h3><a id="connect_development" href="#connect_development">8.3 Connector Development Guide</a></h3>
+
+ <p>This guide describes how developers can write new connectors for Kafka Connect to move data between Kafka and other systems. It briefly reviews a few key concepts and then describes how to create a simple connector.</p>
+
+ <h4><a id="connect_concepts" href="#connect_concepts">Core Concepts and APIs</a></h4>
+
+ <h5><a id="connect_connectorsandtasks" href="#connect_connectorsandtasks">Connectors and Tasks</a></h5>
+
+ <p>To copy data between Kafka and another system, users create a <code>Connector</code> for the system they want to pull data from or push data to. Connectors come in two flavors: <code>SourceConnectors</code> import data from another system (e.g. <code>JDBCSourceConnector</code> would import a relational database into Kafka) and <code>SinkConnectors</code> export data (e.g. <code>HDFSSinkConnector</code> would export the contents of a Kafka topic to an HDFS file).</p>
+
+ <p><code>Connectors</code> do not perform any data copying themselves: their configuration describes the data to be copied, and the <code>Connector</code> is responsible for breaking that job into a set of <code>Tasks</code> that can be distributed to workers. These <code>Tasks</code> also come in two corresponding flavors: <code>SourceTask</code> and <code>SinkTask</code>.</p>
+
+ <p>With an assignment in hand, each <code>Task</code> must copy its subset of the data to or from Kafka. In Kafka Connect, it should always be possible to frame these assignments as a set of input and output streams consisting of records with consistent schemas. Sometimes this mapping is obvious: each file in a set of log files can be considered a stream with each parsed line forming a record using the same schema and offsets stored as byte offsets in the file. In other cases it may [...]
+
+
+ <h5><a id="connect_streamsandrecords" href="#connect_streamsandrecords">Streams and Records</a></h5>
+
+ <p>Each stream should be a sequence of key-value records. Both the keys and values can have complex structure -- many primitive types are provided, but arrays, objects, and nested data structures can be represented as well. The runtime data format does not assume any particular serialization format; this conversion is handled internally by the framework.</p>
+
+ <p>In addition to the key and value, records (both those generated by sources and those delivered to sinks) have associated stream IDs and offsets. These are used by the framework to periodically commit the offsets of data that have been processed so that in the event of failures, processing can resume from the last committed offsets, avoiding unnecessary reprocessing and duplication of events.</p>
+
+ <h5><a id="connect_dynamicconnectors" href="#connect_dynamicconnectors">Dynamic Connectors</a></h5>
+
+ <p>Not all jobs are static, so <code>Connector</code> implementations are also responsible for monitoring the external system for any changes that might require reconfiguration. For example, in the <code>JDBCSourceConnector</code> example, the <code>Connector</code> might assign a set of tables to each <code>Task</code>. When a new table is created, it must discover this so it can assign the new table to one of the <code>Tasks</code> by updating its configuration. When it notices a c [...]
+
+
+ <h4><a id="connect_developing" href="#connect_developing">Developing a Simple Connector</a></h4>
+
+ <p>Developing a connector only requires implementing two interfaces, the <code>Connector</code> and <code>Task</code>. A simple example is included with the source code for Kafka in the <code>file</code> package. This connector is meant for use in standalone mode and has implementations of a <code>SourceConnector</code>/<code>SourceTask</code> to read each line of a file and emit it as a record and a <code>SinkConnector</code>/<code>SinkTask</code> that writes each record to a file.</p>
+
+ <p>The rest of this section will walk through some code to demonstrate the key steps in creating a connector, but developers should also refer to the full example source code as many details are omitted for brevity.</p>
+
+ <h5><a id="connect_connectorexample" href="#connect_connectorexample">Connector Example</a></h5>
+
+ <p>We'll cover the <code>SourceConnector</code> as a simple example. <code>SinkConnector</code> implementations are very similar. Start by creating the class that inherits from <code>SourceConnector</code> and add a couple of fields that will store parsed configuration information (the filename to read from and the topic to send data to):</p>
+
+ <pre class="brush: java;">
+ public class FileStreamSourceConnector extends SourceConnector {
+ private String filename;
+ private String topic;
+ </pre>
+
+ <p>The easiest method to fill in is <code>taskClass()</code>, which defines the class that should be instantiated in worker processes to actually read the data:</p>
+
+ <pre class="brush: java;">
+ @Override
+ public Class<? extends Task> taskClass() {
+ return FileStreamSourceTask.class;
+ }
+ </pre>
+
+ <p>We will define the <code>FileStreamSourceTask</code> class below. Next, we add some standard lifecycle methods, <code>start()</code> and <code>stop()</code></p>:
+
+ <pre class="brush: java;">
+ @Override
+ public void start(Map<String, String> props) {
+ // The complete version includes error handling as well.
+ filename = props.get(FILE_CONFIG);
+ topic = props.get(TOPIC_CONFIG);
+ }
+
+ @Override
+ public void stop() {
+ // Nothing to do since no background monitoring is required.
+ }
+ </pre>
+
+ <p>Finally, the real core of the implementation is in <code>taskConfigs()</code>. In this case we are only
+ handling a single file, so even though we may be permitted to generate more tasks as per the
+ <code>maxTasks</code> argument, we return a list with only one entry:</p>
+
+ <pre class="brush: java;">
+ @Override
+ public List<Map<String, String>> taskConfigs(int maxTasks) {
+ ArrayList<Map<String, String>> configs = new ArrayList<>();
+ // Only one input stream makes sense.
+ Map<String, String> config = new HashMap<>();
+ if (filename != null)
+ config.put(FILE_CONFIG, filename);
+ config.put(TOPIC_CONFIG, topic);
+ configs.add(config);
+ return configs;
+ }
+ </pre>
+
+ <p>Although not used in the example, <code>SourceTask</code> also provides two APIs to commit offsets in the source system: <code>commit</code> and <code>commitRecord</code>. The APIs are provided for source systems which have an acknowledgement mechanism for messages. Overriding these methods allows the source connector to acknowledge messages in the source system, either in bulk or individually, once they have been written to Kafka.
+ The <code>commit</code> API stores the offsets in the source system, up to the offsets that have been returned by <code>poll</code>. The implementation of this API should block until the commit is complete. The <code>commitRecord</code> API saves the offset in the source system for each <code>SourceRecord</code> after it is written to Kafka. As Kafka Connect will record offsets automatically, <code>SourceTask</code>s are not required to implement them. In cases where a connector does [...]
+
+ <p>Even with multiple tasks, this method implementation is usually pretty simple. It just has to determine the number of input tasks, which may require contacting the remote service it is pulling data from, and then divvy them up. Because some patterns for splitting work among tasks are so common, some utilities are provided in <code>ConnectorUtils</code> to simplify these cases.</p>
+
+ <p>Note that this simple example does not include dynamic input. See the discussion in the next section for how to trigger updates to task configs.</p>
+
+ <h5><a id="connect_taskexample" href="#connect_taskexample">Task Example - Source Task</a></h5>
+
+ <p>Next we'll describe the implementation of the corresponding <code>SourceTask</code>. The implementation is short, but too long to cover completely in this guide. We'll use pseudo-code to describe most of the implementation, but you can refer to the source code for the full example.</p>
+
+ <p>Just as with the connector, we need to create a class inheriting from the appropriate base <code>Task</code> class. It also has some standard lifecycle methods:</p>
+
+
+ <pre class="brush: java;">
+ public class FileStreamSourceTask extends SourceTask {
+ String filename;
+ InputStream stream;
+ String topic;
+
+ @Override
+ public void start(Map<String, String> props) {
+ filename = props.get(FileStreamSourceConnector.FILE_CONFIG);
+ stream = openOrThrowError(filename);
+ topic = props.get(FileStreamSourceConnector.TOPIC_CONFIG);
+ }
+
+ @Override
+ public synchronized void stop() {
+ stream.close();
+ }
+ </pre>
+
+ <p>These are slightly simplified versions, but show that these methods should be relatively simple and the only work they should perform is allocating or freeing resources. There are two points to note about this implementation. First, the <code>start()</code> method does not yet handle resuming from a previous offset, which will be addressed in a later section. Second, the <code>stop()</code> method is synchronized. This will be necessary because <code>SourceTasks</code> are given a [...]
+
+ <p>Next, we implement the main functionality of the task, the <code>poll()</code> method which gets events from the input system and returns a <code>List<SourceRecord></code>:</p>
+
+ <pre class="brush: java;">
+ @Override
+ public List<SourceRecord> poll() throws InterruptedException {
+ try {
+ ArrayList<SourceRecord> records = new ArrayList<>();
+ while (streamValid(stream) && records.isEmpty()) {
+ LineAndOffset line = readToNextLine(stream);
+ if (line != null) {
+ Map<String, Object> sourcePartition = Collections.singletonMap("filename", filename);
+ Map<String, Object> sourceOffset = Collections.singletonMap("position", streamOffset);
+ records.add(new SourceRecord(sourcePartition, sourceOffset, topic, Schema.STRING_SCHEMA, line));
+ } else {
+ Thread.sleep(1);
+ }
+ }
+ return records;
+ } catch (IOException e) {
+ // Underlying stream was killed, probably as a result of calling stop. Allow to return
+ // null, and driving thread will handle any shutdown if necessary.
+ }
+ return null;
+ }
+ </pre>
+
+ <p>Again, we've omitted some details, but we can see the important steps: the <code>poll()</code> method is going to be called repeatedly, and for each call it will loop trying to read records from the file. For each line it reads, it also tracks the file offset. It uses this information to create an output <code>SourceRecord</code> with four pieces of information: the source partition (there is only one, the single file being read), source offset (byte offset in the file), output to [...]
+
+ <p>Note that this implementation uses the normal Java <code>InputStream</code> interface and may sleep if data is not available. This is acceptable because Kafka Connect provides each task with a dedicated thread. While task implementations have to conform to the basic <code>poll()</code> interface, they have a lot of flexibility in how they are implemented. In this case, an NIO-based implementation would be more efficient, but this simple approach works, is quick to implement, and i [...]
+
+ <h5><a id="connect_sinktasks" href="#connect_sinktasks">Sink Tasks</a></h5>
+
+ <p>The previous section described how to implement a simple <code>SourceTask</code>. Unlike <code>SourceConnector</code> and <code>SinkConnector</code>, <code>SourceTask</code> and <code>SinkTask</code> have very different interfaces because <code>SourceTask</code> uses a pull interface and <code>SinkTask</code> uses a push interface. Both share the common lifecycle methods, but the <code>SinkTask</code> interface is quite different:</p>
+
+ <pre class="brush: java;">
+ public abstract class SinkTask implements Task {
+ public void initialize(SinkTaskContext context) {
+ this.context = context;
+ }
+
+ public abstract void put(Collection<SinkRecord> records);
+
+ public void flush(Map<TopicPartition, OffsetAndMetadata> currentOffsets) {
+ }
+ </pre>
+
+ <p>The <code>SinkTask</code> documentation contains full details, but this interface is nearly as simple as the <code>SourceTask</code>. The <code>put()</code> method should contain most of the implementation, accepting sets of <code>SinkRecords</code>, performing any required translation, and storing them in the destination system. This method does not need to ensure the data has been fully written to the destination system before returning. In fact, in many cases internal buffering [...]
+
+ <p>The <code>flush()</code> method is used during the offset commit process, which allows tasks to recover from failures and resume from a safe point such that no events will be missed. The method should push any outstanding data to the destination system and then block until the write has been acknowledged. The <code>offsets</code> parameter can often be ignored, but is useful in some cases where implementations want to store offset information in the destination store to provide ex [...]
+ delivery. For example, an HDFS connector could do this and use atomic move operations to make sure the <code>flush()</code> operation atomically commits the data and offsets to a final location in HDFS.</p>
+
+
+ <h5><a id="connect_resuming" href="#connect_resuming">Resuming from Previous Offsets</a></h5>
+
+ <p>The <code>SourceTask</code> implementation included a stream ID (the input filename) and offset (position in the file) with each record. The framework uses this to commit offsets periodically so that in the case of a failure, the task can recover and minimize the number of events that are reprocessed and possibly duplicated (or to resume from the most recent offset if Kafka Connect was stopped gracefully, e.g. in standalone mode or due to a job reconfiguration). This commit proces [...]
+
+ <p>To correctly resume upon startup, the task can use the <code>SourceContext</code> passed into its <code>initialize()</code> method to access the offset data. In <code>initialize()</code>, we would add a bit more code to read the offset (if it exists) and seek to that position:</p>
+
+ <pre class="brush: java;">
+ stream = new FileInputStream(filename);
+ Map<String, Object> offset = context.offsetStorageReader().offset(Collections.singletonMap(FILENAME_FIELD, filename));
+ if (offset != null) {
+ Long lastRecordedOffset = (Long) offset.get("position");
+ if (lastRecordedOffset != null)
+ seekToOffset(stream, lastRecordedOffset);
+ }
+ </pre>
+
+ <p>Of course, you might need to read many keys for each of the input streams. The <code>OffsetStorageReader</code> interface also allows you to issue bulk reads to efficiently load all offsets, then apply them by seeking each input stream to the appropriate position.</p>
+
+ <h4><a id="connect_dynamicio" href="#connect_dynamicio">Dynamic Input/Output Streams</a></h4>
+
+ <p>Kafka Connect is intended to define bulk data copying jobs, such as copying an entire database rather than creating many jobs to copy each table individually. One consequence of this design is that the set of input or output streams for a connector can vary over time.</p>
+
+ <p>Source connectors need to monitor the source system for changes, e.g. table additions/deletions in a database. When they pick up changes, they should notify the framework via the <code>ConnectorContext</code> object that reconfiguration is necessary. For example, in a <code>SourceConnector</code>:</p>
+
+ <pre class="brush: java;">
+ if (inputsChanged())
+ this.context.requestTaskReconfiguration();
+ </pre>
+
+ <p>The framework will promptly request new configuration information and update the tasks, allowing them to gracefully commit their progress before reconfiguring them. Note that in the <code>SourceConnector</code> this monitoring is currently left up to the connector implementation. If an extra thread is required to perform this monitoring, the connector must allocate it itself.</p>
+
+ <p>Ideally this code for monitoring changes would be isolated to the <code>Connector</code> and tasks would not need to worry about them. However, changes can also affect tasks, most commonly when one of their input streams is destroyed in the input system, e.g. if a table is dropped from a database. If the <code>Task</code> encounters the issue before the <code>Connector</code>, which will be common if the <code>Connector</code> needs to poll for changes, the <code>Task</code> will [...]
+
+ <p><code>SinkConnectors</code> usually only have to handle the addition of streams, which may translate to new entries in their outputs (e.g., a new database table). The framework manages any changes to the Kafka input, such as when the set of input topics changes because of a regex subscription. <code>SinkTasks</code> should expect new input streams, which may require creating new resources in the downstream system, such as a new table in a database. The trickiest situation to handl [...]
+
+ <h4><a id="connect_configs" href="#connect_configs">Connect Configuration Validation</a></h4>
+
+ <p>Kafka Connect allows you to validate connector configurations before submitting a connector to be executed and can provide feedback about errors and recommended values. To take advantage of this, connector developers need to provide an implementation of <code>config()</code> to expose the configuration definition to the framework.</p>
+
+ <p>The following code in <code>FileStreamSourceConnector</code> defines the configuration and exposes it to the framework.</p>
+
+ <pre class="brush: java;">
+ private static final ConfigDef CONFIG_DEF = new ConfigDef()
+ .define(FILE_CONFIG, Type.STRING, Importance.HIGH, "Source filename.")
+ .define(TOPIC_CONFIG, Type.STRING, Importance.HIGH, "The topic to publish data to");
+
+ public ConfigDef config() {
+ return CONFIG_DEF;
+ }
+ </pre>
+
+ <p><code>ConfigDef</code> class is used for specifying the set of expected configurations. For each configuration, you can specify the name, the type, the default value, the documentation, the group information, the order in the group, the width of the configuration value and the name suitable for display in the UI. Plus, you can provide special validation logic used for single configuration validation by overriding the <code>Validator</code> class. Moreover, as there may be dependen [...]
+
+ <p>Also, the <code>validate()</code> method in <code>Connector</code> provides a default validation implementation which returns a list of allowed configurations together with configuration errors and recommended values for each configuration. However, it does not use the recommended values for configuration validation. You may provide an override of the default implementation for customized configuration validation, which may use the recommended values.</p>
+
+ <h4><a id="connect_schemas" href="#connect_schemas">Working with Schemas</a></h4>
+
+ <p>The FileStream connectors are good examples because they are simple, but they also have trivially structured data -- each line is just a string. Almost all practical connectors will need schemas with more complex data formats.</p>
+
+ <p>To create more complex data, you'll need to work with the Kafka Connect <code>data</code> API. Most structured records will need to interact with two classes in addition to primitive types: <code>Schema</code> and <code>Struct</code>.</p>
+
+ <p>The API documentation provides a complete reference, but here is a simple example creating a <code>Schema</code> and <code>Struct</code>:</p>
+
+ <pre class="brush: java;">
+ Schema schema = SchemaBuilder.struct().name(NAME)
+ .field("name", Schema.STRING_SCHEMA)
+ .field("age", Schema.INT_SCHEMA)
+ .field("admin", new SchemaBuilder.boolean().defaultValue(false).build())
+ .build();
+
+ Struct struct = new Struct(schema)
+ .put("name", "Barbara Liskov")
+ .put("age", 75);
+ </pre>
+
+ <p>If you are implementing a source connector, you'll need to decide when and how to create schemas. Where possible, you should avoid recomputing them as much as possible. For example, if your connector is guaranteed to have a fixed schema, create it statically and reuse a single instance.</p>
+
+ <p>However, many connectors will have dynamic schemas. One simple example of this is a database connector. Considering even just a single table, the schema will not be predefined for the entire connector (as it varies from table to table). But it also may not be fixed for a single table over the lifetime of the connector since the user may execute an <code>ALTER TABLE</code> command. The connector must be able to detect these changes and react appropriately.</p>
+
+ <p>Sink connectors are usually simpler because they are consuming data and therefore do not need to create schemas. However, they should take just as much care to validate that the schemas they receive have the expected format. When the schema does not match -- usually indicating the upstream producer is generating invalid data that cannot be correctly translated to the destination system -- sink connectors should throw an exception to indicate this error to the system.</p>
+
+ <h4><a id="connect_administration" href="#connect_administration">Kafka Connect Administration</a></h4>
+
+ <p>
+ Kafka Connect's <a href="#connect_rest">REST layer</a> provides a set of APIs to enable administration of the cluster. This includes APIs to view the configuration of connectors and the status of their tasks, as well as to alter their current behavior (e.g. changing configuration and restarting tasks).
+ </p>
+
+ <p>
+ When a connector is first submitted to the cluster, the workers rebalance the full set of connectors in the cluster and their tasks so that each worker has approximately the same amount of work. This same rebalancing procedure is also used when connectors increase or decrease the number of tasks they require, or when a connector's configuration is changed. You can use the REST API to view the current status of a connector and its tasks, including the id of the worker to which each wa [...]
+ </p>
+
+ <pre class="brush: json;">
+ {
+ "name": "file-source",
+ "connector": {
+ "state": "RUNNING",
+ "worker_id": "192.168.1.208:8083"
+ },
+ "tasks": [
+ {
+ "id": 0,
+ "state": "RUNNING",
+ "worker_id": "192.168.1.209:8083"
+ }
+ ]
+ }
+ </pre>
+
+ <p>
+ Connectors and their tasks publish status updates to a shared topic (configured with <code>status.storage.topic</code>) which all workers in the cluster monitor. Because the workers consume this topic asynchronously, there is typically a (short) delay before a state change is visible through the status API. The following states are possible for a connector or one of its tasks:
+ </p>
+
+ <ul>
+ <li><b>UNASSIGNED:</b> The connector/task has not yet been assigned to a worker.</li>
+ <li><b>RUNNING:</b> The connector/task is running.</li>
+ <li><b>PAUSED:</b> The connector/task has been administratively paused.</li>
+ <li><b>FAILED:</b> The connector/task has failed (usually by raising an exception, which is reported in the status output).</li>
+ </ul>
+
+ <p>
+ In most cases, connector and task states will match, though they may be different for short periods of time when changes are occurring or if tasks have failed. For example, when a connector is first started, there may be a noticeable delay before the connector and its tasks have all transitioned to the RUNNING state. States will also diverge when tasks fail since Connect does not automatically restart failed tasks. To restart a connector/task manually, you can use the restart APIs li [...]
+ </p>
+
+ <p>
+ It's sometimes useful to temporarily stop the message processing of a connector. For example, if the remote system is undergoing maintenance, it would be preferable for source connectors to stop polling it for new data instead of filling logs with exception spam. For this use case, Connect offers a pause/resume API. While a source connector is paused, Connect will stop polling it for additional records. While a sink connector is paused, Connect will stop pushing new messages to it. T [...]
+ </p>
+</script>
+
+<div class="p-connect"></div>
diff --git a/11/design.html b/11/design.html
new file mode 100644
index 0000000..69d1941
--- /dev/null
+++ b/11/design.html
@@ -0,0 +1,624 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<script id="design-template" type="text/x-handlebars-template">
+ <h3><a id="majordesignelements" href="#majordesignelements">4.1 Motivation</a></h3>
+ <p>
+ We designed Kafka to be able to act as a unified platform for handling all the real-time data feeds <a href="#introduction">a large company might have</a>. To do this we had to think through a fairly broad set of use cases.
+ <p>
+ It would have to have high-throughput to support high volume event streams such as real-time log aggregation.
+ <p>
+ It would need to deal gracefully with large data backlogs to be able to support periodic data loads from offline systems.
+ <p>
+ It also meant the system would have to handle low-latency delivery to handle more traditional messaging use-cases.
+ <p>
+ We wanted to support partitioned, distributed, real-time processing of these feeds to create new, derived feeds. This motivated our partitioning and consumer model.
+ <p>
+ Finally in cases where the stream is fed into other data systems for serving, we knew the system would have to be able to guarantee fault-tolerance in the presence of machine failures.
+ <p>
+ Supporting these uses led us to a design with a number of unique elements, more akin to a database log than a traditional messaging system. We will outline some elements of the design in the following sections.
+
+ <h3><a id="persistence" href="#persistence">4.2 Persistence</a></h3>
+ <h4><a id="design_filesystem" href="#design_filesystem">Don't fear the filesystem!</a></h4>
+ <p>
+ Kafka relies heavily on the filesystem for storing and caching messages. There is a general perception that "disks are slow" which makes people skeptical that a persistent structure can offer competitive performance.
+ In fact disks are both much slower and much faster than people expect depending on how they are used; and a properly designed disk structure can often be as fast as the network.
+ <p>
+ The key fact about disk performance is that the throughput of hard drives has been diverging from the latency of a disk seek for the last decade. As a result the performance of linear writes on a <a href="http://en.wikipedia.org/wiki/Non-RAID_drive_architectures">JBOD</a>
+ configuration with six 7200rpm SATA RAID-5 array is about 600MB/sec but the performance of random writes is only about 100k/sec—a difference of over 6000X. These linear reads and writes are the most
+ predictable of all usage patterns, and are heavily optimized by the operating system. A modern operating system provides read-ahead and write-behind techniques that prefetch data in large block multiples and
+ group smaller logical writes into large physical writes. A further discussion of this issue can be found in this <a href="http://queue.acm.org/detail.cfm?id=1563874">ACM Queue article</a>; they actually find that
+ <a href="http://deliveryimages.acm.org/10.1145/1570000/1563874/jacobs3.jpg">sequential disk access can in some cases be faster than random memory access!</a>
+ <p>
+ To compensate for this performance divergence, modern operating systems have become increasingly aggressive in their use of main memory for disk caching. A modern OS will happily divert <i>all</i> free memory to
+ disk caching with little performance penalty when the memory is reclaimed. All disk reads and writes will go through this unified cache. This feature cannot easily be turned off without using direct I/O, so even
+ if a process maintains an in-process cache of the data, this data will likely be duplicated in OS pagecache, effectively storing everything twice.
+ <p>
+ Furthermore, we are building on top of the JVM, and anyone who has spent any time with Java memory usage knows two things:
+ <ol>
+ <li>The memory overhead of objects is very high, often doubling the size of the data stored (or worse).</li>
+ <li>Java garbage collection becomes increasingly fiddly and slow as the in-heap data increases.</li>
+ </ol>
+ <p>
+ As a result of these factors using the filesystem and relying on pagecache is superior to maintaining an in-memory cache or other structure—we at least double the available cache by having automatic access
+ to all free memory, and likely double again by storing a compact byte structure rather than individual objects. Doing so will result in a cache of up to 28-30GB on a 32GB machine without GC penalties.
+ Furthermore, this cache will stay warm even if the service is restarted, whereas the in-process cache will need to be rebuilt in memory (which for a 10GB cache may take 10 minutes) or else it will need to start
+ with a completely cold cache (which likely means terrible initial performance). This also greatly simplifies the code as all logic for maintaining coherency between the cache and filesystem is now in the OS,
+ which tends to do so more efficiently and more correctly than one-off in-process attempts. If your disk usage favors linear reads then read-ahead is effectively pre-populating this cache with useful data on each
+ disk read.
+ <p>
+ This suggests a design which is very simple: rather than maintain as much as possible in-memory and flush it all out to the filesystem in a panic when we run out of space, we invert that. All data is immediately
+ written to a persistent log on the filesystem without necessarily flushing to disk. In effect this just means that it is transferred into the kernel's pagecache.
+ <p>
+ This style of pagecache-centric design is described in an <a href="http://varnish-cache.org/wiki/ArchitectNotes">article</a> on the design of Varnish here (along with a healthy dose of arrogance).
+
+ <h4><a id="design_constanttime" href="#design_constanttime">Constant Time Suffices</a></h4>
+ <p>
+ The persistent data structure used in messaging systems are often a per-consumer queue with an associated BTree or other general-purpose random access data structures to maintain metadata about messages.
+ BTrees are the most versatile data structure available, and make it possible to support a wide variety of transactional and non-transactional semantics in the messaging system.
+ They do come with a fairly high cost, though: Btree operations are O(log N). Normally O(log N) is considered essentially equivalent to constant time, but this is not true for disk operations.
+ Disk seeks come at 10 ms a pop, and each disk can do only one seek at a time so parallelism is limited. Hence even a handful of disk seeks leads to very high overhead.
+ Since storage systems mix very fast cached operations with very slow physical disk operations, the observed performance of tree structures is often superlinear as data increases with fixed cache--i.e. doubling
+ your data makes things much worse than twice as slow.
+ <p>
+ Intuitively a persistent queue could be built on simple reads and appends to files as is commonly the case with logging solutions. This structure has the advantage that all operations are O(1) and reads do not
+ block writes or each other. This has obvious performance advantages since the performance is completely decoupled from the data size—one server can now take full advantage of a number of cheap,
+ low-rotational speed 1+TB SATA drives. Though they have poor seek performance, these drives have acceptable performance for large reads and writes and come at 1/3 the price and 3x the capacity.
+ <p>
+ Having access to virtually unlimited disk space without any performance penalty means that we can provide some features not usually found in a messaging system. For example, in Kafka, instead of attempting to
+ delete messages as soon as they are consumed, we can retain messages for a relatively long period (say a week). This leads to a great deal of flexibility for consumers, as we will describe.
+
+ <h3><a id="maximizingefficiency" href="#maximizingefficiency">4.3 Efficiency</a></h3>
+ <p>
+ We have put significant effort into efficiency. One of our primary use cases is handling web activity data, which is very high volume: each page view may generate dozens of writes. Furthermore, we assume each
+ message published is read by at least one consumer (often many), hence we strive to make consumption as cheap as possible.
+ <p>
+ We have also found, from experience building and running a number of similar systems, that efficiency is a key to effective multi-tenant operations. If the downstream infrastructure service can easily become a
+ bottleneck due to a small bump in usage by the application, such small changes will often create problems. By being very fast we help ensure that the application will tip-over under load before the infrastructure.
+ This is particularly important when trying to run a centralized service that supports dozens or hundreds of applications on a centralized cluster as changes in usage patterns are a near-daily occurrence.
+ <p>
+ We discussed disk efficiency in the previous section. Once poor disk access patterns have been eliminated, there are two common causes of inefficiency in this type of system: too many small I/O operations, and
+ excessive byte copying.
+ <p>
+ The small I/O problem happens both between the client and the server and in the server's own persistent operations.
+ <p>
+ To avoid this, our protocol is built around a "message set" abstraction that naturally groups messages together. This allows network requests to group messages together and amortize the overhead of the network
+ roundtrip rather than sending a single message at a time. The server in turn appends chunks of messages to its log in one go, and the consumer fetches large linear chunks at a time.
+ <p>
+ This simple optimization produces orders of magnitude speed up. Batching leads to larger network packets, larger sequential disk operations, contiguous memory blocks, and so on, all of which allows Kafka to turn
+ a bursty stream of random message writes into linear writes that flow to the consumers.
+ <p>
+ The other inefficiency is in byte copying. At low message rates this is not an issue, but under load the impact is significant. To avoid this we employ a standardized binary message format that is shared by the
+ producer, the broker, and the consumer (so data chunks can be transferred without modification between them).
+ <p>
+ The message log maintained by the broker is itself just a directory of files, each populated by a sequence of message sets that have been written to disk in the same format used by the producer and consumer.
+ Maintaining this common format allows optimization of the most important operation: network transfer of persistent log chunks. Modern unix operating systems offer a highly optimized code path for transferring data
+ out of pagecache to a socket; in Linux this is done with the <a href="http://man7.org/linux/man-pages/man2/sendfile.2.html">sendfile system call</a>.
+ <p>
+ To understand the impact of sendfile, it is important to understand the common data path for transfer of data from file to socket:
+ <ol>
+ <li>The operating system reads data from the disk into pagecache in kernel space</li>
+ <li>The application reads the data from kernel space into a user-space buffer</li>
+ <li>The application writes the data back into kernel space into a socket buffer</li>
+ <li>The operating system copies the data from the socket buffer to the NIC buffer where it is sent over the network</li>
+ </ol>
+ <p>
+ This is clearly inefficient, there are four copies and two system calls. Using sendfile, this re-copying is avoided by allowing the OS to send the data from pagecache to the network directly. So in this optimized
+ path, only the final copy to the NIC buffer is needed.
+ <p>
+ We expect a common use case to be multiple consumers on a topic. Using the zero-copy optimization above, data is copied into pagecache exactly once and reused on each consumption instead of being stored in memory
+ and copied out to user-space every time it is read. This allows messages to be consumed at a rate that approaches the limit of the network connection.
+ <p>
+ This combination of pagecache and sendfile means that on a Kafka cluster where the consumers are mostly caught up you will see no read activity on the disks whatsoever as they will be serving data entirely from cache.
+ <p>
+ For more background on the sendfile and zero-copy support in Java, see this <a href="http://www.ibm.com/developerworks/linux/library/j-zerocopy">article</a>.
+
+ <h4><a id="design_compression" href="#design_compression">End-to-end Batch Compression</a></h4>
+ <p>
+ In some cases the bottleneck is actually not CPU or disk but network bandwidth. This is particularly true for a data pipeline that needs to send messages between data centers over a wide-area network. Of course,
+ the user can always compress its messages one at a time without any support needed from Kafka, but this can lead to very poor compression ratios as much of the redundancy is due to repetition between messages of
+ the same type (e.g. field names in JSON or user agents in web logs or common string values). Efficient compression requires compressing multiple messages together rather than compressing each message individually.
+ <p>
+ Kafka supports this with an efficient batching format. A batch of messages can be clumped together compressed and sent to the server in this form. This batch of messages will be written in compressed form and will
+ remain compressed in the log and will only be decompressed by the consumer.
+ <p>
+ Kafka supports GZIP, Snappy and LZ4 compression protocols. More details on compression can be found <a href="https://cwiki.apache.org/confluence/display/KAFKA/Compression">here</a>.
+
+ <h3><a id="theproducer" href="#theproducer">4.4 The Producer</a></h3>
+
+ <h4><a id="design_loadbalancing" href="#design_loadbalancing">Load balancing</a></h4>
+ <p>
+ The producer sends data directly to the broker that is the leader for the partition without any intervening routing tier. To help the producer do this all Kafka nodes can answer a request for metadata about which
+ servers are alive and where the leaders for the partitions of a topic are at any given time to allow the producer to appropriately direct its requests.
+ <p>
+ The client controls which partition it publishes messages to. This can be done at random, implementing a kind of random load balancing, or it can be done by some semantic partitioning function. We expose the interface
+ for semantic partitioning by allowing the user to specify a key to partition by and using this to hash to a partition (there is also an option to override the partition function if need be). For example if the key
+ chosen was a user id then all data for a given user would be sent to the same partition. This in turn will allow consumers to make locality assumptions about their consumption. This style of partitioning is explicitly
+ designed to allow locality-sensitive processing in consumers.
+
+ <h4><a id="design_asyncsend" href="#design_asyncsend">Asynchronous send</a></h4>
+ <p>
+ Batching is one of the big drivers of efficiency, and to enable batching the Kafka producer will attempt to accumulate data in memory and to send out larger batches in a single request. The batching can be configured
+ to accumulate no more than a fixed number of messages and to wait no longer than some fixed latency bound (say 64k or 10 ms). This allows the accumulation of more bytes to send, and few larger I/O operations on the
+ servers. This buffering is configurable and gives a mechanism to trade off a small amount of additional latency for better throughput.
+ <p>
+ Details on <a href="#producerconfigs">configuration</a> and the <a href="http://kafka.apache.org/082/javadoc/index.html?org/apache/kafka/clients/producer/KafkaProducer.html">api</a> for the producer can be found
+ elsewhere in the documentation.
+
+ <h3><a id="theconsumer" href="#theconsumer">4.5 The Consumer</a></h3>
+
+ The Kafka consumer works by issuing "fetch" requests to the brokers leading the partitions it wants to consume. The consumer specifies its offset in the log with each request and receives back a chunk of log
+ beginning from that position. The consumer thus has significant control over this position and can rewind it to re-consume data if need be.
+
+ <h4><a id="design_pull" href="#design_pull">Push vs. pull</a></h4>
+ <p>
+ An initial question we considered is whether consumers should pull data from brokers or brokers should push data to the consumer. In this respect Kafka follows a more traditional design, shared by most messaging
+ systems, where data is pushed to the broker from the producer and pulled from the broker by the consumer. Some logging-centric systems, such as <a href="http://github.com/facebook/scribe">Scribe</a> and
+ <a href="http://flume.apache.org/">Apache Flume</a>, follow a very different push-based path where data is pushed downstream. There are pros and cons to both approaches. However, a push-based system has difficulty
+ dealing with diverse consumers as the broker controls the rate at which data is transferred. The goal is generally for the consumer to be able to consume at the maximum possible rate; unfortunately, in a push
+ system this means the consumer tends to be overwhelmed when its rate of consumption falls below the rate of production (a denial of service attack, in essence). A pull-based system has the nicer property that
+ the consumer simply falls behind and catches up when it can. This can be mitigated with some kind of backoff protocol by which the consumer can indicate it is overwhelmed, but getting the rate of transfer to
+ fully utilize (but never over-utilize) the consumer is trickier than it seems. Previous attempts at building systems in this fashion led us to go with a more traditional pull model.
+ <p>
+ Another advantage of a pull-based system is that it lends itself to aggressive batching of data sent to the consumer. A push-based system must choose to either send a request immediately or accumulate more data
+ and then send it later without knowledge of whether the downstream consumer will be able to immediately process it. If tuned for low latency, this will result in sending a single message at a time only for the
+ transfer to end up being buffered anyway, which is wasteful. A pull-based design fixes this as the consumer always pulls all available messages after its current position in the log (or up to some configurable max
+ size). So one gets optimal batching without introducing unnecessary latency.
+ <p>
+ The deficiency of a naive pull-based system is that if the broker has no data the consumer may end up polling in a tight loop, effectively busy-waiting for data to arrive. To avoid this we have parameters in our
+ pull request that allow the consumer request to block in a "long poll" waiting until data arrives (and optionally waiting until a given number of bytes is available to ensure large transfer sizes).
+ <p>
+ You could imagine other possible designs which would be only pull, end-to-end. The producer would locally write to a local log, and brokers would pull from that with consumers pulling from them. A similar type of
+ "store-and-forward" producer is often proposed. This is intriguing but we felt not very suitable for our target use cases which have thousands of producers. Our experience running persistent data systems at
+ scale led us to feel that involving thousands of disks in the system across many applications would not actually make things more reliable and would be a nightmare to operate. And in practice we have found that we
+ can run a pipeline with strong SLAs at large scale without a need for producer persistence.
+
+ <h4><a id="design_consumerposition" href="#design_consumerposition">Consumer Position</a></h4>
+ Keeping track of <i>what</i> has been consumed is, surprisingly, one of the key performance points of a messaging system.
+ <p>
+ Most messaging systems keep metadata about what messages have been consumed on the broker. That is, as a message is handed out to a consumer, the broker either records that fact locally immediately or it may wait
+ for acknowledgement from the consumer. This is a fairly intuitive choice, and indeed for a single machine server it is not clear where else this state could go. Since the data structures used for storage in many
+ messaging systems scale poorly, this is also a pragmatic choice--since the broker knows what is consumed it can immediately delete it, keeping the data size small.
+ <p>
+ What is perhaps not obvious is that getting the broker and consumer to come into agreement about what has been consumed is not a trivial problem. If the broker records a message as <b>consumed</b> immediately every
+ time it is handed out over the network, then if the consumer fails to process the message (say because it crashes or the request times out or whatever) that message will be lost. To solve this problem, many messaging
+ systems add an acknowledgement feature which means that messages are only marked as <b>sent</b> not <b>consumed</b> when they are sent; the broker waits for a specific acknowledgement from the consumer to record the
+ message as <b>consumed</b>. This strategy fixes the problem of losing messages, but creates new problems. First of all, if the consumer processes the message but fails before it can send an acknowledgement then the
+ message will be consumed twice. The second problem is around performance, now the broker must keep multiple states about every single message (first to lock it so it is not given out a second time, and then to mark
+ it as permanently consumed so that it can be removed). Tricky problems must be dealt with, like what to do with messages that are sent but never acknowledged.
+ <p>
+ Kafka handles this differently. Our topic is divided into a set of totally ordered partitions, each of which is consumed by exactly one consumer within each subscribing consumer group at any given time. This means
+ that the position of a consumer in each partition is just a single integer, the offset of the next message to consume. This makes the state about what has been consumed very small, just one number for each partition.
+ This state can be periodically checkpointed. This makes the equivalent of message acknowledgements very cheap.
+ <p>
+ There is a side benefit of this decision. A consumer can deliberately <i>rewind</i> back to an old offset and re-consume data. This violates the common contract of a queue, but turns out to be an essential feature
+ for many consumers. For example, if the consumer code has a bug and is discovered after some messages are consumed, the consumer can re-consume those messages once the bug is fixed.
+
+ <h4><a id="design_offlineload" href="#design_offlineload">Offline Data Load</a></h4>
+
+ Scalable persistence allows for the possibility of consumers that only periodically consume such as batch data loads that periodically bulk-load data into an offline system such as Hadoop or a relational data
+ warehouse.
+ <p>
+ In the case of Hadoop we parallelize the data load by splitting the load over individual map tasks, one for each node/topic/partition combination, allowing full parallelism in the loading. Hadoop provides the task
+ management, and tasks which fail can restart without danger of duplicate data—they simply restart from their original position.
+
+ <h3><a id="semantics" href="#semantics">4.6 Message Delivery Semantics</a></h3>
+ <p>
+ Now that we understand a little about how producers and consumers work, let's discuss the semantic guarantees Kafka provides between producer and consumer. Clearly there are multiple possible message delivery
+ guarantees that could be provided:
+ <ul>
+ <li>
+ <i>At most once</i>—Messages may be lost but are never redelivered.
+ </li>
+ <li>
+ <i>At least once</i>—Messages are never lost but may be redelivered.
+ </li>
+ <li>
+ <i>Exactly once</i>—this is what people actually want, each message is delivered once and only once.
+ </li>
+ </ul>
+
+ It's worth noting that this breaks down into two problems: the durability guarantees for publishing a message and the guarantees when consuming a message.
+ <p>
+ Many systems claim to provide "exactly once" delivery semantics, but it is important to read the fine print, most of these claims are misleading (i.e. they don't translate to the case where consumers or producers
+ can fail, cases where there are multiple consumer processes, or cases where data written to disk can be lost).
+ <p>
+ Kafka's semantics are straight-forward. When publishing a message we have a notion of the message being "committed" to the log. Once a published message is committed it will not be lost as long as one broker that
+ replicates the partition to which this message was written remains "alive". The definition of committed message, alive partition as well as a description of which types of failures we attempt to handle will be
+ described in more detail in the next section. For now let's assume a perfect, lossless broker and try to understand the guarantees to the producer and consumer. If a producer attempts to publish a message and
+ experiences a network error it cannot be sure if this error happened before or after the message was committed. This is similar to the semantics of inserting into a database table with an autogenerated key.
+ <p>
+ Prior to 0.11.0.0, if a producer failed to receive a response indicating that a message was committed, it had little choice but to resend the message. This provides at-least-once delivery semantics since the
+ message may be written to the log again during resending if the original request had in fact succeeded. Since 0.11.0.0, the Kafka producer also supports an idempotent delivery option which guarantees that resending
+ will not result in duplicate entries in the log. To achieve this, the broker assigns each producer an ID and deduplicates messages using a sequence number that is sent by the producer along with every message.
+ Also beginning with 0.11.0.0, the producer supports the ability to send messages to multiple topic partitions using transaction-like semantics: i.e. either all messages are successfully written or none of them are.
+ The main use case for this is exactly-once processing between Kafka topics (described below).
+ <p>
+ Not all use cases require such strong guarantees. For uses which are latency sensitive we allow the producer to specify the durability level it desires. If the producer specifies that it wants to wait on the message
+ being committed this can take on the order of 10 ms. However the producer can also specify that it wants to perform the send completely asynchronously or that it wants to wait only until the leader (but not
+ necessarily the followers) have the message.
+ <p>
+ Now let's describe the semantics from the point-of-view of the consumer. All replicas have the exact same log with the same offsets. The consumer controls its position in this log. If the consumer never crashed it
+ could just store this position in memory, but if the consumer fails and we want this topic partition to be taken over by another process the new process will need to choose an appropriate position from which to start
+ processing. Let's say the consumer reads some messages -- it has several options for processing the messages and updating its position.
+ <ol>
+ <li>It can read the messages, then save its position in the log, and finally process the messages. In this case there is a possibility that the consumer process crashes after saving its position but before saving
+ the output of its message processing. In this case the process that took over processing would start at the saved position even though a few messages prior to that position had not been processed. This corresponds
+ to "at-most-once" semantics as in the case of a consumer failure messages may not be processed.
+ <li>It can read the messages, process the messages, and finally save its position. In this case there is a possibility that the consumer process crashes after processing messages but before saving its position.
+ In this case when the new process takes over the first few messages it receives will already have been processed. This corresponds to the "at-least-once" semantics in the case of consumer failure. In many cases
+ messages have a primary key and so the updates are idempotent (receiving the same message twice just overwrites a record with another copy of itself).
+ </ol>
+ <p>
+ So what about exactly once semantics (i.e. the thing you actually want)? When consuming from a Kafka topic and producing to another topic (as in a <a href="https://kafka.apache.org/documentation/streams">Kafka Streams</a>
+ application), we can leverage the new transactional producer capabilities in 0.11.0.0 that were mentioned above. The consumer's position is stored as a message in a topic, so we can write the offset to Kafka in the
+ same transaction as the output topics receiving the processed data. If the transaction is aborted, the consumer's position will revert to its old value and the produced data on the output topics will not be visible
+ to other consumers, depending on their "isolation level." In the default "read_uncommitted" isolation level, all messages are visible to consumers even if they were part of an aborted transaction,
+ but in "read_committed," the consumer will only return messages from transactions which were committed (and any messages which were not part of a transaction).
+ <p>
+ When writing to an external system, the limitation is in the need to coordinate the consumer's position with what is actually stored as output. The classic way of achieving this would be to introduce a two-phase
+ commit between the storage of the consumer position and the storage of the consumers output. But this can be handled more simply and generally by letting the consumer store its offset in the same place as
+ its output. This is better because many of the output systems a consumer might want to write to will not support a two-phase commit. As an example of this, consider a
+ <a href="https://kafka.apache.org/documentation/#connect">Kafka Connect</a> connector which populates data in HDFS along with the offsets of the data it reads so that it is guaranteed that either data and
+ offsets are both updated or neither is. We follow similar patterns for many other data systems which require these stronger semantics and for which the messages do not have a primary key to allow for deduplication.
+ <p>
+ So effectively Kafka supports exactly-once delivery in <a href="https://kafka.apache.org/documentation/streams">Kafka Streams</a>, and the transactional producer/consumer can be used generally to provide
+ exactly-once delivery when transfering and processing data between Kafka topics. Exactly-once delivery for other destination systems generally requires cooperation with such systems, but Kafka provides the
+ offset which makes implementing this feasible (see also <a href="https://kafka.apache.org/documentation/#connect">Kafka Connect</a>). Otherwise, Kafka guarantees at-least-once delivery by default, and allows
+ the user to implement at-most-once delivery by disabling retries on the producer and committing offsets in the consumer prior to processing a batch of messages.
+
+ <h3><a id="replication" href="#replication">4.7 Replication</a></h3>
+ <p>
+ Kafka replicates the log for each topic's partitions across a configurable number of servers (you can set this replication factor on a topic-by-topic basis). This allows automatic failover to these replicas when a
+ server in the cluster fails so messages remain available in the presence of failures.
+ <p>
+ Other messaging systems provide some replication-related features, but, in our (totally biased) opinion, this appears to be a tacked-on thing, not heavily used, and with large downsides: slaves are inactive,
+ throughput is heavily impacted, it requires fiddly manual configuration, etc. Kafka is meant to be used with replication by default—in fact we implement un-replicated topics as replicated topics where the
+ replication factor is one.
+ <p>
+ The unit of replication is the topic partition. Under non-failure conditions, each partition in Kafka has a single leader and zero or more followers. The total number of replicas including the leader constitute the
+ replication factor. All reads and writes go to the leader of the partition. Typically, there are many more partitions than brokers and the leaders are evenly distributed among brokers. The logs on the followers are
+ identical to the leader's log—all have the same offsets and messages in the same order (though, of course, at any given time the leader may have a few as-yet unreplicated messages at the end of its log).
+ <p>
+ Followers consume messages from the leader just as a normal Kafka consumer would and apply them to their own log. Having the followers pull from the leader has the nice property of allowing the follower to naturally
+ batch together log entries they are applying to their log.
+ <p>
+ As with most distributed systems automatically handling failures requires having a precise definition of what it means for a node to be "alive". For Kafka node liveness has two conditions
+ <ol>
+ <li>A node must be able to maintain its session with ZooKeeper (via ZooKeeper's heartbeat mechanism)
+ <li>If it is a slave it must replicate the writes happening on the leader and not fall "too far" behind
+ </ol>
+ We refer to nodes satisfying these two conditions as being "in sync" to avoid the vagueness of "alive" or "failed". The leader keeps track of the set of "in sync" nodes. If a follower dies, gets stuck, or falls
+ behind, the leader will remove it from the list of in sync replicas. The determination of stuck and lagging replicas is controlled by the replica.lag.time.max.ms configuration.
+ <p>
+ In distributed systems terminology we only attempt to handle a "fail/recover" model of failures where nodes suddenly cease working and then later recover (perhaps without knowing that they have died). Kafka does not
+ handle so-called "Byzantine" failures in which nodes produce arbitrary or malicious responses (perhaps due to bugs or foul play).
+ <p>
+ We can now more precisely define that a message is considered committed when all in sync replicas for that partition have applied it to their log.
+ Only committed messages are ever given out to the consumer. This means that the consumer need not worry about potentially seeing a message that could be lost if the leader fails. Producers, on the other hand,
+ have the option of either waiting for the message to be committed or not, depending on their preference for tradeoff between latency and durability. This preference is controlled by the acks setting that the
+ producer uses.
+ Note that topics have a setting for the "minimum number" of in-sync replicas that is checked when the producer requests acknowledgment that a message
+ has been written to the full set of in-sync replicas. If a less stringent acknowledgement is requested by the producer, then the message can be committed, and consumed,
+ even if the number of in-sync replicas is lower than the minimum (e.g. it can be as low as just the leader).
+ <p>
+ The guarantee that Kafka offers is that a committed message will not be lost, as long as there is at least one in sync replica alive, at all times.
+ <p>
+ Kafka will remain available in the presence of node failures after a short fail-over period, but may not remain available in the presence of network partitions.
+
+ <h4><a id="design_replicatedlog" href="#design_replicatedlog">Replicated Logs: Quorums, ISRs, and State Machines (Oh my!)</a></h4>
+
+ At its heart a Kafka partition is a replicated log. The replicated log is one of the most basic primitives in distributed data systems, and there are many approaches for implementing one. A replicated log can be
+ used by other systems as a primitive for implementing other distributed systems in the <a href="http://en.wikipedia.org/wiki/State_machine_replication">state-machine style</a>.
+ <p>
+ A replicated log models the process of coming into consensus on the order of a series of values (generally numbering the log entries 0, 1, 2, ...). There are many ways to implement this, but the simplest and fastest
+ is with a leader who chooses the ordering of values provided to it. As long as the leader remains alive, all followers need to only copy the values and ordering the leader chooses.
+ <p>
+ Of course if leaders didn't fail we wouldn't need followers! When the leader does die we need to choose a new leader from among the followers. But followers themselves may fall behind or crash so we must ensure we
+ choose an up-to-date follower. The fundamental guarantee a log replication algorithm must provide is that if we tell the client a message is committed, and the leader fails, the new leader we elect must also have
+ that message. This yields a tradeoff: if the leader waits for more followers to acknowledge a message before declaring it committed then there will be more potentially electable leaders.
+ <p>
+ If you choose the number of acknowledgements required and the number of logs that must be compared to elect a leader such that there is guaranteed to be an overlap, then this is called a Quorum.
+ <p>
+ A common approach to this tradeoff is to use a majority vote for both the commit decision and the leader election. This is not what Kafka does, but let's explore it anyway to understand the tradeoffs. Let's say we
+ have 2<i>f</i>+1 replicas. If <i>f</i>+1 replicas must receive a message prior to a commit being declared by the leader, and if we elect a new leader by electing the follower with the most complete log from at least
+ <i>f</i>+1 replicas, then, with no more than <i>f</i> failures, the leader is guaranteed to have all committed messages. This is because among any <i>f</i>+1 replicas, there must be at least one replica that contains
+ all committed messages. That replica's log will be the most complete and therefore will be selected as the new leader. There are many remaining details that each algorithm must handle (such as precisely defined what
+ makes a log more complete, ensuring log consistency during leader failure or changing the set of servers in the replica set) but we will ignore these for now.
+ <p>
+ This majority vote approach has a very nice property: the latency is dependent on only the fastest servers. That is, if the replication factor is three, the latency is determined by the faster slave not the slower one.
+ <p>
+ There are a rich variety of algorithms in this family including ZooKeeper's
+ <a href="http://web.archive.org/web/20140602093727/http://www.stanford.edu/class/cs347/reading/zab.pdf">Zab</a>,
+ <a href="https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf">Raft</a>,
+ and <a href="http://pmg.csail.mit.edu/papers/vr-revisited.pdf">Viewstamped Replication</a>.
+ The most similar academic publication we are aware of to Kafka's actual implementation is
+ <a href="http://research.microsoft.com/apps/pubs/default.aspx?id=66814">PacificA</a> from Microsoft.
+ <p>
+ The downside of majority vote is that it doesn't take many failures to leave you with no electable leaders. To tolerate one failure requires three copies of the data, and to tolerate two failures requires five copies
+ of the data. In our experience having only enough redundancy to tolerate a single failure is not enough for a practical system, but doing every write five times, with 5x the disk space requirements and 1/5th the
+ throughput, is not very practical for large volume data problems. This is likely why quorum algorithms more commonly appear for shared cluster configuration such as ZooKeeper but are less common for primary data
+ storage. For example in HDFS the namenode's high-availability feature is built on a <a href="http://blog.cloudera.com/blog/2012/10/quorum-based-journaling-in-cdh4-1">majority-vote-based journal</a>, but this more
+ expensive approach is not used for the data itself.
+ <p>
+ Kafka takes a slightly different approach to choosing its quorum set. Instead of majority vote, Kafka dynamically maintains a set of in-sync replicas (ISR) that are caught-up to the leader. Only members of this set
+ are eligible for election as leader. A write to a Kafka partition is not considered committed until <i>all</i> in-sync replicas have received the write. This ISR set is persisted to ZooKeeper whenever it changes.
+ Because of this, any replica in the ISR is eligible to be elected leader. This is an important factor for Kafka's usage model where there are many partitions and ensuring leadership balance is important.
+ With this ISR model and <i>f+1</i> replicas, a Kafka topic can tolerate <i>f</i> failures without losing committed messages.
+ <p>
+ For most use cases we hope to handle, we think this tradeoff is a reasonable one. In practice, to tolerate <i>f</i> failures, both the majority vote and the ISR approach will wait for the same number of replicas to
+ acknowledge before committing a message (e.g. to survive one failure a majority quorum needs three replicas and one acknowledgement and the ISR approach requires two replicas and one acknowledgement).
+ The ability to commit without the slowest servers is an advantage of the majority vote approach. However, we think it is ameliorated by allowing the client to choose whether they block on the message commit or not,
+ and the additional throughput and disk space due to the lower required replication factor is worth it.
+ <p>
+ Another important design distinction is that Kafka does not require that crashed nodes recover with all their data intact. It is not uncommon for replication algorithms in this space to depend on the existence of
+ "stable storage" that cannot be lost in any failure-recovery scenario without potential consistency violations. There are two primary problems with this assumption. First, disk errors are the most common problem we
+ observe in real operation of persistent data systems and they often do not leave data intact. Secondly, even if this were not a problem, we do not want to require the use of fsync on every write for our consistency
+ guarantees as this can reduce performance by two to three orders of magnitude. Our protocol for allowing a replica to rejoin the ISR ensures that before rejoining, it must fully re-sync again even if it lost unflushed
+ data in its crash.
+
+ <h4><a id="design_uncleanleader" href="#design_uncleanleader">Unclean leader election: What if they all die?</a></h4>
+
+ Note that Kafka's guarantee with respect to data loss is predicated on at least one replica remaining in sync. If all the nodes replicating a partition die, this guarantee no longer holds.
+ <p>
+ However a practical system needs to do something reasonable when all the replicas die. If you are unlucky enough to have this occur, it is important to consider what will happen. There are two behaviors that could be
+ implemented:
+ <ol>
+ <li>Wait for a replica in the ISR to come back to life and choose this replica as the leader (hopefully it still has all its data).
+ <li>Choose the first replica (not necessarily in the ISR) that comes back to life as the leader.
+ </ol>
+ <p>
+ This is a simple tradeoff between availability and consistency. If we wait for replicas in the ISR, then we will remain unavailable as long as those replicas are down. If such replicas were destroyed or their data
+ was lost, then we are permanently down. If, on the other hand, a non-in-sync replica comes back to life and we allow it to become leader, then its log becomes the source of truth even though it is not guaranteed to
+ have every committed message. By default from version 0.11.0.0, Kafka chooses the first strategy and favor waiting for a consistent replica. This behavior can be changed using
+ configuration property unclean.leader.election.enable, to support use cases where uptime is preferable to consistency.
+ <p>
+ This dilemma is not specific to Kafka. It exists in any quorum-based scheme. For example in a majority voting scheme, if a majority of servers suffer a permanent failure, then you must either choose to lose 100% of
+ your data or violate consistency by taking what remains on an existing server as your new source of truth.
+
+
+ <h4><a id="design_ha" href="#design_ha">Availability and Durability Guarantees</a></h4>
+
+ When writing to Kafka, producers can choose whether they wait for the message to be acknowledged by 0,1 or all (-1) replicas.
+ Note that "acknowledgement by all replicas" does not guarantee that the full set of assigned replicas have received the message. By default, when acks=all, acknowledgement happens as soon as all the current in-sync
+ replicas have received the message. For example, if a topic is configured with only two replicas and one fails (i.e., only one in sync replica remains), then writes that specify acks=all will succeed. However, these
+ writes could be lost if the remaining replica also fails.
+
+ Although this ensures maximum availability of the partition, this behavior may be undesirable to some users who prefer durability over availability. Therefore, we provide two topic-level configurations that can be
+ used to prefer message durability over availability:
+ <ol>
+ <li> Disable unclean leader election - if all replicas become unavailable, then the partition will remain unavailable until the most recent leader becomes available again. This effectively prefers unavailability
+ over the risk of message loss. See the previous section on Unclean Leader Election for clarification. </li>
+ <li> Specify a minimum ISR size - the partition will only accept writes if the size of the ISR is above a certain minimum, in order to prevent the loss of messages that were written to just a single replica,
+ which subsequently becomes unavailable. This setting only takes effect if the producer uses acks=all and guarantees that the message will be acknowledged by at least this many in-sync replicas.
+ This setting offers a trade-off between consistency and availability. A higher setting for minimum ISR size guarantees better consistency since the message is guaranteed to be written to more replicas which reduces
+ the probability that it will be lost. However, it reduces availability since the partition will be unavailable for writes if the number of in-sync replicas drops below the minimum threshold. </li>
+ </ol>
+
+
+ <h4><a id="design_replicamanagment" href="#design_replicamanagment">Replica Management</a></h4>
+
+ The above discussion on replicated logs really covers only a single log, i.e. one topic partition. However a Kafka cluster will manage hundreds or thousands of these partitions. We attempt to balance partitions
+ within a cluster in a round-robin fashion to avoid clustering all partitions for high-volume topics on a small number of nodes. Likewise we try to balance leadership so that each node is the leader for a proportional
+ share of its partitions.
+ <p>
+ It is also important to optimize the leadership election process as that is the critical window of unavailability. A naive implementation of leader election would end up running an election per partition for all
+ partitions a node hosted when that node failed. Instead, we elect one of the brokers as the "controller". This controller detects failures at the broker level and is responsible for changing the leader of all
+ affected partitions in a failed broker. The result is that we are able to batch together many of the required leadership change notifications which makes the election process far cheaper and faster for a large number
+ of partitions. If the controller fails, one of the surviving brokers will become the new controller.
+
+ <h3><a id="compaction" href="#compaction">4.8 Log Compaction</a></h3>
+
+ Log compaction ensures that Kafka will always retain at least the last known value for each message key within the log of data for a single topic partition. It addresses use cases and scenarios such as restoring
+ state after application crashes or system failure, or reloading caches after application restarts during operational maintenance. Let's dive into these use cases in more detail and then describe how compaction works.
+ <p>
+ So far we have described only the simpler approach to data retention where old log data is discarded after a fixed period of time or when the log reaches some predetermined size. This works well for temporal event
+ data such as logging where each record stands alone. However an important class of data streams are the log of changes to keyed, mutable data (for example, the changes to a database table).
+ <p>
+ Let's discuss a concrete example of such a stream. Say we have a topic containing user email addresses; every time a user updates their email address we send a message to this topic using their user id as the
+ primary key. Now say we send the following messages over some time period for a user with id 123, each message corresponding to a change in email address (messages for other ids are omitted):
+ <pre class="brush: text;">
+ 123 => bill@microsoft.com
+ .
+ .
+ .
+ 123 => bill@gatesfoundation.org
+ .
+ .
+ .
+ 123 => bill@gmail.com
+ </pre>
+ Log compaction gives us a more granular retention mechanism so that we are guaranteed to retain at least the last update for each primary key (e.g. <code>bill@gmail.com</code>). By doing this we guarantee that the
+ log contains a full snapshot of the final value for every key not just keys that changed recently. This means downstream consumers can restore their own state off this topic without us having to retain a complete
+ log of all changes.
+ <p>
+ Let's start by looking at a few use cases where this is useful, then we'll see how it can be used.
+ <ol>
+ <li><i>Database change subscription</i>. It is often necessary to have a data set in multiple data systems, and often one of these systems is a database of some kind (either a RDBMS or perhaps a new-fangled key-value
+ store). For example you might have a database, a cache, a search cluster, and a Hadoop cluster. Each change to the database will need to be reflected in the cache, the search cluster, and eventually in Hadoop.
+ In the case that one is only handling the real-time updates you only need recent log. But if you want to be able to reload the cache or restore a failed search node you may need a complete data set.
+ <li><i>Event sourcing</i>. This is a style of application design which co-locates query processing with application design and uses a log of changes as the primary store for the application.
+ <li><i>Journaling for high-availability</i>. A process that does local computation can be made fault-tolerant by logging out changes that it makes to its local state so another process can reload these changes and
+ carry on if it should fail. A concrete example of this is handling counts, aggregations, and other "group by"-like processing in a stream query system. Samza, a real-time stream-processing framework,
+ <a href="http://samza.apache.org/learn/documentation/0.7.0/container/state-management.html">uses this feature</a> for exactly this purpose.
+ </ol>
+ In each of these cases one needs primarily to handle the real-time feed of changes, but occasionally, when a machine crashes or data needs to be re-loaded or re-processed, one needs to do a full load.
+ Log compaction allows feeding both of these use cases off the same backing topic.
+
+ This style of usage of a log is described in more detail in <a href="http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying">this blog post</a>.
+ <p>
+ The general idea is quite simple. If we had infinite log retention, and we logged each change in the above cases, then we would have captured the state of the system at each time from when it first began.
+ Using this complete log, we could restore to any point in time by replaying the first N records in the log. This hypothetical complete log is not very practical for systems that update a single record many times
+ as the log will grow without bound even for a stable dataset. The simple log retention mechanism which throws away old updates will bound space but the log is no longer a way to restore the current state—now
+ restoring from the beginning of the log no longer recreates the current state as old updates may not be captured at all.
+ <p>
+ Log compaction is a mechanism to give finer-grained per-record retention, rather than the coarser-grained time-based retention. The idea is to selectively remove records where we have a more recent update with the
+ same primary key. This way the log is guaranteed to have at least the last state for each key.
+ <p>
+ This retention policy can be set per-topic, so a single cluster can have some topics where retention is enforced by size or time and other topics where retention is enforced by compaction.
+ <p>
+ This functionality is inspired by one of LinkedIn's oldest and most successful pieces of infrastructure—a database changelog caching service called <a href="https://github.com/linkedin/databus">Databus</a>.
+ Unlike most log-structured storage systems Kafka is built for subscription and organizes data for fast linear reads and writes. Unlike Databus, Kafka acts as a source-of-truth store so it is useful even in
+ situations where the upstream data source would not otherwise be replayable.
+
+ <h4><a id="design_compactionbasics" href="#design_compactionbasics">Log Compaction Basics</a></h4>
+
+ Here is a high-level picture that shows the logical structure of a Kafka log with the offset for each message.
+ <p>
+ <img class="centered" src="/{{version}}/images/log_cleaner_anatomy.png">
+ <p>
+ The head of the log is identical to a traditional Kafka log. It has dense, sequential offsets and retains all messages. Log compaction adds an option for handling the tail of the log. The picture above shows a log
+ with a compacted tail. Note that the messages in the tail of the log retain the original offset assigned when they were first written—that never changes. Note also that all offsets remain valid positions in
+ the log, even if the message with that offset has been compacted away; in this case this position is indistinguishable from the next highest offset that does appear in the log. For example, in the picture above the
+ offsets 36, 37, and 38 are all equivalent positions and a read beginning at any of these offsets would return a message set beginning with 38.
+ <p>
+ Compaction also allows for deletes. A message with a key and a null payload will be treated as a delete from the log. This delete marker will cause any prior message with that key to be removed (as would any new
+ message with that key), but delete markers are special in that they will themselves be cleaned out of the log after a period of time to free up space. The point in time at which deletes are no longer retained is
+ marked as the "delete retention point" in the above diagram.
+ <p>
+ The compaction is done in the background by periodically recopying log segments. Cleaning does not block reads and can be throttled to use no more than a configurable amount of I/O throughput to avoid impacting
+ producers and consumers. The actual process of compacting a log segment looks something like this:
+ <p>
+ <img class="centered" src="/{{version}}/images/log_compaction.png">
+ <p>
+ <h4><a id="design_compactionguarantees" href="#design_compactionguarantees">What guarantees does log compaction provide?</a></h4>
+
+ Log compaction guarantees the following:
+ <ol>
+ <li>Any consumer that stays caught-up to within the head of the log will see every message that is written; these messages will have sequential offsets. The topic's <code>min.compaction.lag.ms</code> can be used to
+ guarantee the minimum length of time must pass after a message is written before it could be compacted. I.e. it provides a lower bound on how long each message will remain in the (uncompacted) head.
+ <li>Ordering of messages is always maintained. Compaction will never re-order messages, just remove some.
+ <li>The offset for a message never changes. It is the permanent identifier for a position in the log.
+ <li>Any consumer progressing from the start of the log will see at least the final state of all records in the order they were written. Additionally, all delete markers for deleted records will be seen, provided
+ the consumer reaches the head of the log in a time period less than the topic's <code>delete.retention.ms</code> setting (the default is 24 hours). In other words: since the removal of delete markers happens
+ concurrently with reads, it is possible for a consumer to miss delete markers if it lags by more than <code>delete.retention.ms</code>.
+ </ol>
+
+ <h4><a id="design_compactiondetails" href="#design_compactiondetails">Log Compaction Details</a></h4>
+
+ Log compaction is handled by the log cleaner, a pool of background threads that recopy log segment files, removing records whose key appears in the head of the log. Each compactor thread works as follows:
+ <ol>
+ <li>It chooses the log that has the highest ratio of log head to log tail
+ <li>It creates a succinct summary of the last offset for each key in the head of the log
+ <li>It recopies the log from beginning to end removing keys which have a later occurrence in the log. New, clean segments are swapped into the log immediately so the additional disk space required is just one
+ additional log segment (not a fully copy of the log).
+ <li>The summary of the log head is essentially just a space-compact hash table. It uses exactly 24 bytes per entry. As a result with 8GB of cleaner buffer one cleaner iteration can clean around 366GB of log head
+ (assuming 1k messages).
+ </ol>
+ <p>
+ <h4><a id="design_compactionconfig" href="#design_compactionconfig">Configuring The Log Cleaner</a></h4>
+
+ The log cleaner is enabled by default. This will start the pool of cleaner threads.
+ To enable log cleaning on a particular topic you can add the log-specific property
+ <pre class="brush: text;"> log.cleanup.policy=compact</pre>
+ This can be done either at topic creation time or using the alter topic command.
+ <p>
+ The log cleaner can be configured to retain a minimum amount of the uncompacted "head" of the log. This is enabled by setting the compaction time lag.
+ <pre class="brush: text;"> log.cleaner.min.compaction.lag.ms</pre>
+
+ This can be used to prevent messages newer than a minimum message age from being subject to compaction. If not set, all log segments are eligible for compaction except for the last segment, i.e. the one currently
+ being written to. The active segment will not be compacted even if all of its messages are older than the minimum compaction time lag.
+ </p>
+ <p>
+ Further cleaner configurations are described <a href="/documentation.html#brokerconfigs">here</a>.
+
+ <h3><a id="design_quotas" href="#design_quotas">4.9 Quotas</a></h3>
+ <p>
+ Kafka cluster has the ability to enforce quotas on requests to control the broker resources used by clients. Two types
+ of client quotas can be enforced by Kafka brokers for each group of clients sharing a quota:
+ <ol>
+ <li>Network bandwidth quotas define byte-rate thresholds (since 0.9)</li>
+ <li>Request rate quotas define CPU utilization thresholds as a percentage of network and I/O threads (since 0.11)</li>
+ </ol>
+ </p>
+
+ <h4><a id="design_quotasnecessary" href="#design_quotasnecessary">Why are quotas necessary?</a></h4>
+ <p>
+ It is possible for producers and consumers to produce/consume very high volumes of data or generate requests at a very high
+ rate and thus monopolize broker resources, cause network saturation and generally DOS other clients and the brokers themselves.
+ Having quotas protects against these issues and is all the more important in large multi-tenant clusters where a small set of badly behaved clients can degrade user experience for the well behaved ones.
+ In fact, when running Kafka as a service this even makes it possible to enforce API limits according to an agreed upon contract.
+ </p>
+ <h4><a id="design_quotasgroups" href="#design_quotasgroups">Client groups</a></h4>
+ The identity of Kafka clients is the user principal which represents an authenticated user in a secure cluster. In a cluster that supports unauthenticated clients, user principal is a grouping of unauthenticated
+ users
+ chosen by the broker using a configurable <code>PrincipalBuilder</code>. Client-id is a logical grouping of clients with a meaningful name chosen by the client application. The tuple (user, client-id) defines
+ a secure logical group of clients that share both user principal and client-id.
+ <p>
+ Quotas can be applied to (user, client-id), user or client-id groups. For a given connection, the most specific quota matching the connection is applied. All connections of a quota group share the quota configured for the group.
+ For example, if (user="test-user", client-id="test-client") has a produce quota of 10MB/sec, this is shared across all producer instances of user "test-user" with the client-id "test-client".
+ </p>
+ <h4><a id="design_quotasconfig" href="#design_quotasconfig">Quota Configuration</a></h4>
+ <p>
+ Quota configuration may be defined for (user, client-id), user and client-id groups. It is possible to override the default quota at any of the quota levels that needs a higher (or even lower) quota.
+ The mechanism is similar to the per-topic log config overrides.
+ User and (user, client-id) quota overrides are written to ZooKeeper under <i><b>/config/users</b></i> and client-id quota overrides are written under <i><b>/config/clients</b></i>.
+ These overrides are read by all brokers and are effective immediately. This lets us change quotas without having to do a rolling restart of the entire cluster. See <a href="#quotas">here</a> for details.
+ Default quotas for each group may also be updated dynamically using the same mechanism.
+ </p>
+ <p>
+ The order of precedence for quota configuration is:
+ <ol>
+ <li>/config/users/<user>/clients/<client-id></li>
+ <li>/config/users/<user>/clients/<default></li>
+ <li>/config/users/<user></li>
+ <li>/config/users/<default>/clients/<client-id></li>
+ <li>/config/users/<default>/clients/<default></li>
+ <li>/config/users/<default></li>
+ <li>/config/clients/<client-id></li>
+ <li>/config/clients/<default></li>
+ </ol>
+
+ Broker properties (quota.producer.default, quota.consumer.default) can also be used to set defaults of network bandwidth quotas for client-id groups. These properties are being deprecated and will be removed in a later release.
+ Default quotas for client-id can be set in Zookeeper similar to the other quota overrides and defaults.
+ </p>
+ <h4><a id="design_quotasbandwidth" href="#design_quotasbandwidth">Network Bandwidth Quotas</a></h4>
+ <p>
+ Network bandwidth quotas are defined as the byte rate threshold for each group of clients sharing a quota.
+ By default, each unique client group receives a fixed quota in bytes/sec as configured by the cluster.
+ This quota is defined on a per-broker basis. Each group of clients can publish/fetch a maximum of X bytes/sec
+ per broker before clients are throttled.
+ </p>
+ <h4><a id="design_quotascpu" href="#design_quotascpu">Request Rate Quotas</a></h4>
+ <p>
+ Request rate quotas are defined as the percentage of time a client can utilize on request handler I/O
+ threads and network threads of each broker within a quota window. A quota of <tt>n%</tt> represents
+ <tt>n%</tt> of one thread, so the quota is out of a total capacity of <tt>((num.io.threads + num.network.threads) * 100)%</tt>.
+ Each group of clients may use a total percentage of upto <tt>n%</tt> across all I/O and network threads in a quota
+ window before being throttled. Since the number of threads allocated for I/O and network threads are typically based
+ on the number of cores available on the broker host, request rate quotas represent the total percentage of CPU
+ that may be used by each group of clients sharing the quota.
+ </p>
+ <h4><a id="design_quotasenforcement" href="#design_quotasenforcement">Enforcement</a></h4>
+ <p>
+ By default, each unique client group receives a fixed quota as configured by the cluster.
+ This quota is defined on a per-broker basis. Each client can utilize this quota per broker before it gets throttled. We decided that defining these quotas per broker is much better than
+ having a fixed cluster wide bandwidth per client because that would require a mechanism to share client quota usage among all the brokers. This can be harder to get right than the quota implementation itself!
+ </p>
+ <p>
+ How does a broker react when it detects a quota violation? In our solution, the broker does not return an error rather it attempts to slow down a client exceeding its quota.
+ It computes the amount of delay needed to bring a guilty client under its quota and delays the response for that time. This approach keeps the quota violation transparent to clients
+ (outside of client-side metrics). This also keeps them from having to implement any special backoff and retry behavior which can get tricky. In fact, bad client behavior (retry without backoff)
+ can exacerbate the very problem quotas are trying to solve.
+ </p>
+ <p>
+ Byte-rate and thread utilization are measured over multiple small windows (e.g. 30 windows of 1 second each) in order to detect and correct quota violations quickly. Typically, having large measurement windows
+ (for e.g. 10 windows of 30 seconds each) leads to large bursts of traffic followed by long delays which is not great in terms of user experience.
+ </p>
+</script>
+
+<div class="p-design"></div>
diff --git a/11/documentation.html b/11/documentation.html
new file mode 100644
index 0000000..0536535
--- /dev/null
+++ b/11/documentation.html
@@ -0,0 +1,83 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<script><!--#include virtual="js/templateData.js" --></script>
+
+<!--#include virtual="../includes/_header.htm" -->
+<!--#include virtual="../includes/_top.htm" -->
+
+
+<div class="content documentation documentation--current">
+ <!--#include virtual="../includes/_nav.htm" -->
+ <div class="right">
+ <!--#include virtual="../includes/_docs_banner.htm" -->
+ <h1>Documentation</h1>
+ <h3>Kafka 1.1 Documentation</h3>
+ Prior releases: <a href="/07/documentation.html">0.7.x</a>, <a href="/08/documentation.html">0.8.0</a>, <a href="/081/documentation.html">0.8.1.X</a>, <a href="/082/documentation.html">0.8.2.X</a>, <a href="/090/documentation.html">0.9.0.X</a>, <a href="/0100/documentation.html">0.10.0.X</a>, <a href="/0101/documentation.html">0.10.1.X</a>, <a href="/0102/documentation.html">0.10.2.X</a>, <a href="/0110/documentation.html">0.11.0.X</a>, <a href="/10/documentation.html">1.0.X</a>.
+
+ <!--#include virtual="toc.html" -->
+
+ <h2><a id="gettingStarted" href="#gettingStarted">1. Getting Started</a></h2>
+ <h3><a id="introduction" href="#introduction">1.1 Introduction</a></h3>
+ <!--#include virtual="introduction.html" -->
+ <h3><a id="uses" href="#uses">1.2 Use Cases</a></h3>
+ <!--#include virtual="uses.html" -->
+ <h3><a id="quickstart" href="#quickstart">1.3 Quick Start</a></h3>
+ <!--#include virtual="quickstart.html" -->
+ <h3><a id="ecosystem" href="#ecosystem">1.4 Ecosystem</a></h3>
+ <!--#include virtual="ecosystem.html" -->
+ <h3><a id="upgrade" href="#upgrade">1.5 Upgrading From Previous Versions</a></h3>
+ <!--#include virtual="upgrade.html" -->
+
+ <h2><a id="api" href="#api">2. APIs</a></h2>
+
+ <!--#include virtual="api.html" -->
+
+ <h2><a id="configuration" href="#configuration">3. Configuration</a></h2>
+
+ <!--#include virtual="configuration.html" -->
+
+ <h2><a id="design" href="#design">4. Design</a></h2>
+
+ <!--#include virtual="design.html" -->
+
+ <h2><a id="implementation" href="#implementation">5. Implementation</a></h2>
+
+ <!--#include virtual="implementation.html" -->
+
+ <h2><a id="operations" href="#operations">6. Operations</a></h2>
+
+ <!--#include virtual="ops.html" -->
+
+ <h2><a id="security" href="#security">7. Security</a></h2>
+ <!--#include virtual="security.html" -->
+
+ <h2><a id="connect" href="#connect">8. Kafka Connect</a></h2>
+ <!--#include virtual="connect.html" -->
+
+ <h2><a id="streams" href="/11/documentation/streams">9. Kafka Streams</a></h2>
+ <p>
+ Kafka Streams is a client library for processing and analyzing data stored in Kafka. It builds upon important stream processing concepts such as properly distinguishing between event time and processing time, windowing support, exactly-once processing semantics and simple yet efficient management of application state.
+ </p>
+ <p>
+ Kafka Streams has a <b>low barrier to entry</b>: You can quickly write and run a small-scale proof-of-concept on a single machine; and you only need to run additional instances of your application on multiple machines to scale up to high-volume production workloads. Kafka Streams transparently handles the load balancing of multiple instances of the same application by leveraging Kafka's parallelism model.
+ </p>
+
+ <p>Learn More about Kafka Streams read <a href="/11/documentation/streams">this</a> Section.</p>
+
+<!--#include virtual="../includes/_footer.htm" -->
+<!--#include virtual="../includes/_docs_footer.htm" -->
diff --git a/11/documentation/index.html b/11/documentation/index.html
new file mode 100644
index 0000000..1d7507f
--- /dev/null
+++ b/11/documentation/index.html
@@ -0,0 +1,18 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!--#include virtual="../documentation.html" -->
\ No newline at end of file
diff --git a/11/documentation/streams/architecture.html b/11/documentation/streams/architecture.html
new file mode 100644
index 0000000..ad7b323
--- /dev/null
+++ b/11/documentation/streams/architecture.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../streams/architecture.html" -->
diff --git a/11/documentation/streams/core-concepts.html b/11/documentation/streams/core-concepts.html
new file mode 100644
index 0000000..d699b79
--- /dev/null
+++ b/11/documentation/streams/core-concepts.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../streams/core-concepts.html" -->
diff --git a/11/documentation/streams/developer-guide/app-reset-tool.html b/11/documentation/streams/developer-guide/app-reset-tool.html
new file mode 100644
index 0000000..64a43aa
--- /dev/null
+++ b/11/documentation/streams/developer-guide/app-reset-tool.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/app-reset-tool.html" -->
diff --git a/11/documentation/streams/developer-guide/config-streams.html b/11/documentation/streams/developer-guide/config-streams.html
new file mode 100644
index 0000000..979f66d
--- /dev/null
+++ b/11/documentation/streams/developer-guide/config-streams.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/config-streams.html" -->
diff --git a/11/documentation/streams/developer-guide/datatypes.html b/11/documentation/streams/developer-guide/datatypes.html
new file mode 100644
index 0000000..98dd3a1
--- /dev/null
+++ b/11/documentation/streams/developer-guide/datatypes.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/datatypes.html" -->
diff --git a/11/documentation/streams/developer-guide/dsl-api.html b/11/documentation/streams/developer-guide/dsl-api.html
new file mode 100644
index 0000000..1bbc06d
--- /dev/null
+++ b/11/documentation/streams/developer-guide/dsl-api.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/dsl-api.html" -->
diff --git a/11/documentation/streams/developer-guide/index.html b/11/documentation/streams/developer-guide/index.html
new file mode 100644
index 0000000..3a61247
--- /dev/null
+++ b/11/documentation/streams/developer-guide/index.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/index.html" -->
diff --git a/11/documentation/streams/developer-guide/interactive-queries.html b/11/documentation/streams/developer-guide/interactive-queries.html
new file mode 100644
index 0000000..0506012
--- /dev/null
+++ b/11/documentation/streams/developer-guide/interactive-queries.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/interactive-queries.html" -->
diff --git a/11/documentation/streams/developer-guide/manage-topics.html b/11/documentation/streams/developer-guide/manage-topics.html
new file mode 100644
index 0000000..f422554
--- /dev/null
+++ b/11/documentation/streams/developer-guide/manage-topics.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/manage-topics.html" -->
diff --git a/11/documentation/streams/developer-guide/memory-mgmt.html b/11/documentation/streams/developer-guide/memory-mgmt.html
new file mode 100644
index 0000000..024e137
--- /dev/null
+++ b/11/documentation/streams/developer-guide/memory-mgmt.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/memory-mgmt.html" -->
diff --git a/11/documentation/streams/developer-guide/processor-api.html b/11/documentation/streams/developer-guide/processor-api.html
new file mode 100644
index 0000000..9e9ab91
--- /dev/null
+++ b/11/documentation/streams/developer-guide/processor-api.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/processor-api.html" -->
diff --git a/11/documentation/streams/developer-guide/running-app.html b/11/documentation/streams/developer-guide/running-app.html
new file mode 100644
index 0000000..05d5f0b
--- /dev/null
+++ b/11/documentation/streams/developer-guide/running-app.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/running-app.html" -->
diff --git a/11/documentation/streams/developer-guide/security.html b/11/documentation/streams/developer-guide/security.html
new file mode 100644
index 0000000..5d6e5f0
--- /dev/null
+++ b/11/documentation/streams/developer-guide/security.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/security.html" -->
diff --git a/11/documentation/streams/developer-guide/testing.html b/11/documentation/streams/developer-guide/testing.html
new file mode 100644
index 0000000..4753e66
--- /dev/null
+++ b/11/documentation/streams/developer-guide/testing.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/testing.html" -->
diff --git a/11/documentation/streams/developer-guide/write-streams.html b/11/documentation/streams/developer-guide/write-streams.html
new file mode 100644
index 0000000..976c6fe
--- /dev/null
+++ b/11/documentation/streams/developer-guide/write-streams.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../../streams/developer-guide/write-streams.html" -->
diff --git a/11/documentation/streams/index.html b/11/documentation/streams/index.html
new file mode 100644
index 0000000..5ff3b3b
--- /dev/null
+++ b/11/documentation/streams/index.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../streams/index.html" -->
diff --git a/11/documentation/streams/quickstart.html b/11/documentation/streams/quickstart.html
new file mode 100644
index 0000000..efb0234
--- /dev/null
+++ b/11/documentation/streams/quickstart.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../streams/quickstart.html" -->
diff --git a/11/documentation/streams/tutorial.html b/11/documentation/streams/tutorial.html
new file mode 100644
index 0000000..e2cf401
--- /dev/null
+++ b/11/documentation/streams/tutorial.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../streams/tutorial.html" -->
diff --git a/11/documentation/streams/upgrade-guide.html b/11/documentation/streams/upgrade-guide.html
new file mode 100644
index 0000000..b1b3200
--- /dev/null
+++ b/11/documentation/streams/upgrade-guide.html
@@ -0,0 +1,19 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<!-- should always link the latest release's documentation -->
+<!--#include virtual="../../streams/upgrade-guide.html" -->
diff --git a/11/ecosystem.html b/11/ecosystem.html
new file mode 100644
index 0000000..5fbcec5
--- /dev/null
+++ b/11/ecosystem.html
@@ -0,0 +1,18 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+There are a plethora of tools that integrate with Kafka outside the main distribution. The <a href="https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem"> ecosystem page</a> lists many of these, including stream processing systems, Hadoop integration, monitoring, and deployment tools.
diff --git a/11/generated/admin_client_config.html b/11/generated/admin_client_config.html
new file mode 100644
index 0000000..9e3938a
--- /dev/null
+++ b/11/generated/admin_client_config.html
@@ -0,0 +1,86 @@
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>bootstrap.servers</td></td><td>A list of host/port pairs to use for establishing the initial connection to the Kafka cluster. The client will make use of all servers irrespective of which servers are specified here for bootstrapping—this list only impacts the initial hosts used to discover the full set of servers. This list should be in the form <code>host1:port1,host2:port2,...</code>. Since these servers are just used for the initial connection to discover the full cluster me [...]
+<tr>
+<td>ssl.key.password</td></td><td>The password of the private key in the key store file. This is optional for client.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.keystore.location</td></td><td>The location of the key store file. This is optional for client and can be used for two-way authentication for client.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.keystore.password</td></td><td>The store password for the key store file. This is optional for client and only needed if ssl.keystore.location is configured. </td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.truststore.location</td></td><td>The location of the trust store file. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.truststore.password</td></td><td>The password for the trust store file. If a password is not set access to the truststore is still available, but integrity checking is disabled.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>client.id</td></td><td>An id string to pass to the server when making requests. The purpose of this is to be able to track the source of requests beyond just ip/port by allowing a logical application name to be included in server-side request logging.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>connections.max.idle.ms</td></td><td>Close idle connections after the number of milliseconds specified by this config.</td></td><td>long</td></td><td>300000</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>receive.buffer.bytes</td></td><td>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>65536</td></td><td>[-1,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>request.timeout.ms</td></td><td>The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted.</td></td><td>int</td></td><td>120000</td></td><td>[0,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.jaas.config</td></td><td>JAAS login context parameters for SASL connections in the format used by JAAS configuration files. JAAS configuration file format is described <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/LoginConfigFile.html">here</a>. The format for the value is: '<loginModuleClass> <controlFlag> (<optionName>=<optionValue>)*;'</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.kerberos.service.name</td></td><td>The Kerberos principal name that Kafka runs as. This can be defined either in Kafka's JAAS config or in Kafka's config.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.mechanism</td></td><td>SASL mechanism used for client connections. This may be any mechanism for which a security provider is available. GSSAPI is the default mechanism.</td></td><td>string</td></td><td>GSSAPI</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>security.protocol</td></td><td>Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.</td></td><td>string</td></td><td>PLAINTEXT</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>send.buffer.bytes</td></td><td>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>131072</td></td><td>[-1,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.enabled.protocols</td></td><td>The list of protocols enabled for SSL connections.</td></td><td>list</td></td><td>TLSv1.2,TLSv1.1,TLSv1</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.keystore.type</td></td><td>The file format of the key store file. This is optional for client.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.protocol</td></td><td>The SSL protocol used to generate the SSLContext. Default setting is TLS, which is fine for most cases. Allowed values in recent JVMs are TLS, TLSv1.1 and TLSv1.2. SSL, SSLv2 and SSLv3 may be supported in older JVMs, but their usage is discouraged due to known security vulnerabilities.</td></td><td>string</td></td><td>TLS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.provider</td></td><td>The name of the security provider used for SSL connections. Default value is the default security provider of the JVM.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.truststore.type</td></td><td>The file format of the trust store file.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>metadata.max.age.ms</td></td><td>The period of time in milliseconds after which we force a refresh of metadata even if we haven't seen any partition leadership changes to proactively discover any new brokers or partitions.</td></td><td>long</td></td><td>300000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metric.reporters</td></td><td>A list of classes to use as metrics reporters. Implementing the <code>org.apache.kafka.common.metrics.MetricsReporter</code> interface allows plugging in classes that will be notified of new metric creation. The JmxReporter is always included to register JMX statistics.</td></td><td>list</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.num.samples</td></td><td>The number of samples maintained to compute metrics.</td></td><td>int</td></td><td>2</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.recording.level</td></td><td>The highest recording level for metrics.</td></td><td>string</td></td><td>INFO</td></td><td>[INFO, DEBUG]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.sample.window.ms</td></td><td>The window of time a metrics sample is computed over.</td></td><td>long</td></td><td>30000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.max.ms</td></td><td>The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.</td></td><td>long</td></td><td>1000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.ms</td></td><td>The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker.</td></td><td>long</td></td><td>50</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>retries</td></td><td>Setting a value greater than zero will cause the client to resend any request that fails with a potentially transient error.</td></td><td>int</td></td><td>5</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>retry.backoff.ms</td></td><td>The amount of time to wait before attempting to retry a failed request. This avoids repeatedly sending requests in a tight loop under some failure scenarios.</td></td><td>long</td></td><td>100</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.kinit.cmd</td></td><td>Kerberos kinit command path.</td></td><td>string</td></td><td>/usr/bin/kinit</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.min.time.before.relogin</td></td><td>Login thread sleep time between refresh attempts.</td></td><td>long</td></td><td>60000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.jitter</td></td><td>Percentage of random jitter added to the renewal time.</td></td><td>double</td></td><td>0.05</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.window.factor</td></td><td>Login thread will sleep until the specified window factor of time from last refresh to ticket's expiry has been reached, at which time it will try to renew the ticket.</td></td><td>double</td></td><td>0.8</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.cipher.suites</td></td><td>A list of cipher suites. This is a named combination of authentication, encryption, MAC and key exchange algorithm used to negotiate the security settings for a network connection using TLS or SSL network protocol. By default all the available cipher suites are supported.</td></td><td>list</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.endpoint.identification.algorithm</td></td><td>The endpoint identification algorithm to validate server hostname using server certificate. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.keymanager.algorithm</td></td><td>The algorithm used by key manager factory for SSL connections. Default value is the key manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>SunX509</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.secure.random.implementation</td></td><td>The SecureRandom PRNG implementation to use for SSL cryptography operations. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.trustmanager.algorithm</td></td><td>The algorithm used by trust manager factory for SSL connections. Default value is the trust manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>PKIX</td></td><td></td></td><td>low</td></td></tr>
+</tbody></table>
diff --git a/11/generated/connect_config.html b/11/generated/connect_config.html
new file mode 100644
index 0000000..46f83be
--- /dev/null
+++ b/11/generated/connect_config.html
@@ -0,0 +1,156 @@
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>config.storage.topic</td></td><td>The name of the Kafka topic where connector configurations are stored</td></td><td>string</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>group.id</td></td><td>A unique string that identifies the Connect cluster group this worker belongs to.</td></td><td>string</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>key.converter</td></td><td>Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the keys in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro.</td></td><td>class</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>offset.storage.topic</td></td><td>The name of the Kafka topic where connector offsets are stored</td></td><td>string</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>status.storage.topic</td></td><td>The name of the Kafka topic where connector and task status are stored</td></td><td>string</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>value.converter</td></td><td>Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the values in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro.</td></td><td>class</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>internal.key.converter</td></td><td>Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the keys in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro. This setting controls the format used for internal bookkeeping data used by the framework, such as confi [...]
+<tr>
+<td>internal.value.converter</td></td><td>Converter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the values in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro. This setting controls the format used for internal bookkeeping data used by the framework, such as c [...]
+<tr>
+<td>bootstrap.servers</td></td><td>A list of host/port pairs to use for establishing the initial connection to the Kafka cluster. The client will make use of all servers irrespective of which servers are specified here for bootstrapping—this list only impacts the initial hosts used to discover the full set of servers. This list should be in the form <code>host1:port1,host2:port2,...</code>. Since these servers are just used for the initial connection to discover the full cluster me [...]
+<tr>
+<td>heartbeat.interval.ms</td></td><td>The expected time between heartbeats to the group coordinator when using Kafka's group management facilities. Heartbeats are used to ensure that the worker's session stays active and to facilitate rebalancing when new members join or leave the group. The value must be set lower than <code>session.timeout.ms</code>, but typically should be set no higher than 1/3 of that value. It can be adjusted even lower to control the expected time for normal reba [...]
+<tr>
+<td>rebalance.timeout.ms</td></td><td>The maximum allowed time for each worker to join the group once a rebalance has begun. This is basically a limit on the amount of time needed for all tasks to flush any pending data and commit offsets. If the timeout is exceeded, then the worker will be removed from the group, which will cause offset commit failures.</td></td><td>int</td></td><td>60000</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>session.timeout.ms</td></td><td>The timeout used to detect worker failures. The worker sends periodic heartbeats to indicate its liveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker will remove the worker from the group and initiate a rebalance. Note that the value must be in the allowable range as configured in the broker configuration by <code>group.min.session.timeout.ms</code> and <code>group.max.sessio [...]
+<tr>
+<td>ssl.key.password</td></td><td>The password of the private key in the key store file. This is optional for client.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.keystore.location</td></td><td>The location of the key store file. This is optional for client and can be used for two-way authentication for client.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.keystore.password</td></td><td>The store password for the key store file. This is optional for client and only needed if ssl.keystore.location is configured. </td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.truststore.location</td></td><td>The location of the trust store file. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.truststore.password</td></td><td>The password for the trust store file. If a password is not set access to the truststore is still available, but integrity checking is disabled.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>connections.max.idle.ms</td></td><td>Close idle connections after the number of milliseconds specified by this config.</td></td><td>long</td></td><td>540000</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>receive.buffer.bytes</td></td><td>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>32768</td></td><td>[0,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>request.timeout.ms</td></td><td>The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted.</td></td><td>int</td></td><td>40000</td></td><td>[0,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.jaas.config</td></td><td>JAAS login context parameters for SASL connections in the format used by JAAS configuration files. JAAS configuration file format is described <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/LoginConfigFile.html">here</a>. The format for the value is: '<loginModuleClass> <controlFlag> (<optionName>=<optionValue>)*;'</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.kerberos.service.name</td></td><td>The Kerberos principal name that Kafka runs as. This can be defined either in Kafka's JAAS config or in Kafka's config.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.mechanism</td></td><td>SASL mechanism used for client connections. This may be any mechanism for which a security provider is available. GSSAPI is the default mechanism.</td></td><td>string</td></td><td>GSSAPI</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>security.protocol</td></td><td>Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.</td></td><td>string</td></td><td>PLAINTEXT</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>send.buffer.bytes</td></td><td>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>131072</td></td><td>[0,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.enabled.protocols</td></td><td>The list of protocols enabled for SSL connections.</td></td><td>list</td></td><td>TLSv1.2,TLSv1.1,TLSv1</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.keystore.type</td></td><td>The file format of the key store file. This is optional for client.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.protocol</td></td><td>The SSL protocol used to generate the SSLContext. Default setting is TLS, which is fine for most cases. Allowed values in recent JVMs are TLS, TLSv1.1 and TLSv1.2. SSL, SSLv2 and SSLv3 may be supported in older JVMs, but their usage is discouraged due to known security vulnerabilities.</td></td><td>string</td></td><td>TLS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.provider</td></td><td>The name of the security provider used for SSL connections. Default value is the default security provider of the JVM.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.truststore.type</td></td><td>The file format of the trust store file.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>worker.sync.timeout.ms</td></td><td>When the worker is out of sync with other workers and needs to resynchronize configurations, wait up to this amount of time before giving up, leaving the group, and waiting a backoff period before rejoining.</td></td><td>int</td></td><td>3000</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>worker.unsync.backoff.ms</td></td><td>When the worker is out of sync with other workers and fails to catch up within worker.sync.timeout.ms, leave the Connect cluster for this long before rejoining.</td></td><td>int</td></td><td>300000</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>access.control.allow.methods</td></td><td>Sets the methods supported for cross origin requests by setting the Access-Control-Allow-Methods header. The default value of the Access-Control-Allow-Methods header allows cross origin requests for GET, POST and HEAD.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>access.control.allow.origin</td></td><td>Value to set the Access-Control-Allow-Origin header to for REST API requests.To enable cross origin access, set this to the domain of the application that should be permitted to access the API, or '*' to allow access from any domain. The default value only allows access from the domain of the REST API.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>client.id</td></td><td>An id string to pass to the server when making requests. The purpose of this is to be able to track the source of requests beyond just ip/port by allowing a logical application name to be included in server-side request logging.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>config.storage.replication.factor</td></td><td>Replication factor used when creating the configuration storage topic</td></td><td>short</td></td><td>3</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>header.converter</td></td><td>HeaderConverter class used to convert between Kafka Connect format and the serialized form that is written to Kafka. This controls the format of the header values in messages written to or read from Kafka, and since this is independent of connectors it allows any connector to work with any serialization format. Examples of common formats include JSON and Avro. By default, the SimpleHeaderConverter is used to serialize header values to strings and deseria [...]
+<tr>
+<td>listeners</td></td><td>List of comma-separated URIs the REST API will listen on. The supported protocols are HTTP and HTTPS.
+ Specify hostname as 0.0.0.0 to bind to all interfaces.
+ Leave hostname empty to bind to default interface.
+ Examples of legal listener lists: HTTP://myhost:8083,HTTPS://myhost:8084</td></td><td>list</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>metadata.max.age.ms</td></td><td>The period of time in milliseconds after which we force a refresh of metadata even if we haven't seen any partition leadership changes to proactively discover any new brokers or partitions.</td></td><td>long</td></td><td>300000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metric.reporters</td></td><td>A list of classes to use as metrics reporters. Implementing the <code>org.apache.kafka.common.metrics.MetricsReporter</code> interface allows plugging in classes that will be notified of new metric creation. The JmxReporter is always included to register JMX statistics.</td></td><td>list</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.num.samples</td></td><td>The number of samples maintained to compute metrics.</td></td><td>int</td></td><td>2</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.recording.level</td></td><td>The highest recording level for metrics.</td></td><td>string</td></td><td>INFO</td></td><td>[INFO, DEBUG]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.sample.window.ms</td></td><td>The window of time a metrics sample is computed over.</td></td><td>long</td></td><td>30000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>offset.flush.interval.ms</td></td><td>Interval at which to try committing offsets for tasks.</td></td><td>long</td></td><td>60000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>offset.flush.timeout.ms</td></td><td>Maximum number of milliseconds to wait for records to flush and partition offset data to be committed to offset storage before cancelling the process and restoring the offset data to be committed in a future attempt.</td></td><td>long</td></td><td>5000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>offset.storage.partitions</td></td><td>The number of partitions used when creating the offset storage topic</td></td><td>int</td></td><td>25</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>offset.storage.replication.factor</td></td><td>Replication factor used when creating the offset storage topic</td></td><td>short</td></td><td>3</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>plugin.path</td></td><td>List of paths separated by commas (,) that contain plugins (connectors, converters, transformations). The list should consist of top level directories that include any combination of:
+a) directories immediately containing jars with plugins and their dependencies
+b) uber-jars with plugins and their dependencies
+c) directories immediately containing the package directory structure of classes of plugins and their dependencies
+Note: symlinks will be followed to discover dependencies or plugins.
+Examples: plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors</td></td><td>list</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.max.ms</td></td><td>The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.</td></td><td>long</td></td><td>1000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.ms</td></td><td>The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker.</td></td><td>long</td></td><td>50</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>rest.advertised.host.name</td></td><td>If this is set, this is the hostname that will be given out to other workers to connect to.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>rest.advertised.listener</td></td><td>Sets the advertised listener (HTTP or HTTPS) which will be given to other workers to use.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>rest.advertised.port</td></td><td>If this is set, this is the port that will be given out to other workers to connect to.</td></td><td>int</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>rest.host.name</td></td><td>Hostname for the REST API. If this is set, it will only bind to this interface.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>rest.port</td></td><td>Port for the REST API to listen on.</td></td><td>int</td></td><td>8083</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>retry.backoff.ms</td></td><td>The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios.</td></td><td>long</td></td><td>100</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.kinit.cmd</td></td><td>Kerberos kinit command path.</td></td><td>string</td></td><td>/usr/bin/kinit</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.min.time.before.relogin</td></td><td>Login thread sleep time between refresh attempts.</td></td><td>long</td></td><td>60000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.jitter</td></td><td>Percentage of random jitter added to the renewal time.</td></td><td>double</td></td><td>0.05</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.window.factor</td></td><td>Login thread will sleep until the specified window factor of time from last refresh to ticket's expiry has been reached, at which time it will try to renew the ticket.</td></td><td>double</td></td><td>0.8</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.cipher.suites</td></td><td>A list of cipher suites. This is a named combination of authentication, encryption, MAC and key exchange algorithm used to negotiate the security settings for a network connection using TLS or SSL network protocol. By default all the available cipher suites are supported.</td></td><td>list</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.client.auth</td></td><td>Configures kafka broker to request client authentication. The following settings are common: <ul> <li><code>ssl.client.auth=required</code> If set to required client authentication is required. <li><code>ssl.client.auth=requested</code> This means client authentication is optional. unlike requested , if this option is set client can choose not to provide authentication information about itself <li><code>ssl.client.auth=none</code> This means client authe [...]
+<tr>
+<td>ssl.endpoint.identification.algorithm</td></td><td>The endpoint identification algorithm to validate server hostname using server certificate. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.keymanager.algorithm</td></td><td>The algorithm used by key manager factory for SSL connections. Default value is the key manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>SunX509</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.secure.random.implementation</td></td><td>The SecureRandom PRNG implementation to use for SSL cryptography operations. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.trustmanager.algorithm</td></td><td>The algorithm used by trust manager factory for SSL connections. Default value is the trust manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>PKIX</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>status.storage.partitions</td></td><td>The number of partitions used when creating the status storage topic</td></td><td>int</td></td><td>5</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>status.storage.replication.factor</td></td><td>Replication factor used when creating the status storage topic</td></td><td>short</td></td><td>3</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>task.shutdown.graceful.timeout.ms</td></td><td>Amount of time to wait for tasks to shutdown gracefully. This is the total amount of time, not per task. All task have shutdown triggered, then they are waited on sequentially.</td></td><td>long</td></td><td>5000</td></td><td></td></td><td>low</td></td></tr>
+</tbody></table>
diff --git a/11/generated/connect_metrics.html b/11/generated/connect_metrics.html
new file mode 100644
index 0000000..e1c4fb3
--- /dev/null
+++ b/11/generated/connect_metrics.html
@@ -0,0 +1,158 @@
+<table class="data-table"><tbody>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.connect:type=connect-worker-metrics</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>connector-count</td><td>The number of connectors run in this worker.</td></tr>
+<tr>
+<td></td><td>connector-startup-attempts-total</td><td>The total number of connector startups that this worker has attempted.</td></tr>
+<tr>
+<td></td><td>connector-startup-failure-percentage</td><td>The average percentage of this worker's connectors starts that failed.</td></tr>
+<tr>
+<td></td><td>connector-startup-failure-total</td><td>The total number of connector starts that failed.</td></tr>
+<tr>
+<td></td><td>connector-startup-success-percentage</td><td>The average percentage of this worker's connectors starts that succeeded.</td></tr>
+<tr>
+<td></td><td>connector-startup-success-total</td><td>The total number of connector starts that succeeded.</td></tr>
+<tr>
+<td></td><td>task-count</td><td>The number of tasks run in this worker.</td></tr>
+<tr>
+<td></td><td>task-startup-attempts-total</td><td>The total number of task startups that this worker has attempted.</td></tr>
+<tr>
+<td></td><td>task-startup-failure-percentage</td><td>The average percentage of this worker's tasks starts that failed.</td></tr>
+<tr>
+<td></td><td>task-startup-failure-total</td><td>The total number of task starts that failed.</td></tr>
+<tr>
+<td></td><td>task-startup-success-percentage</td><td>The average percentage of this worker's tasks starts that succeeded.</td></tr>
+<tr>
+<td></td><td>task-startup-success-total</td><td>The total number of task starts that succeeded.</td></tr>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.connect:type=connect-worker-rebalance-metrics</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>completed-rebalances-total</td><td>The total number of rebalances completed by this worker.</td></tr>
+<tr>
+<td></td><td>epoch</td><td>The epoch or generation number of this worker.</td></tr>
+<tr>
+<td></td><td>leader-name</td><td>The name of the group leader.</td></tr>
+<tr>
+<td></td><td>rebalance-avg-time-ms</td><td>The average time in milliseconds spent by this worker to rebalance.</td></tr>
+<tr>
+<td></td><td>rebalance-max-time-ms</td><td>The maximum time in milliseconds spent by this worker to rebalance.</td></tr>
+<tr>
+<td></td><td>rebalancing</td><td>Whether this worker is currently rebalancing.</td></tr>
+<tr>
+<td></td><td>time-since-last-rebalance-ms</td><td>The time in milliseconds since this worker completed the most recent rebalance.</td></tr>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.connect:type=connector-metrics,connector="{connector}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>connector-class</td><td>The name of the connector class.</td></tr>
+<tr>
+<td></td><td>connector-type</td><td>The type of the connector. One of 'source' or 'sink'.</td></tr>
+<tr>
+<td></td><td>connector-version</td><td>The version of the connector class, as reported by the connector.</td></tr>
+<tr>
+<td></td><td>status</td><td>The status of the connector. One of 'unassigned', 'running', 'paused', 'failed', or 'destroyed'.</td></tr>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.connect:type=connector-task-metrics,connector="{connector}",task="{task}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>batch-size-avg</td><td>The average size of the batches processed by the connector.</td></tr>
+<tr>
+<td></td><td>batch-size-max</td><td>The maximum size of the batches processed by the connector.</td></tr>
+<tr>
+<td></td><td>offset-commit-avg-time-ms</td><td>The average time in milliseconds taken by this task to commit offsets.</td></tr>
+<tr>
+<td></td><td>offset-commit-failure-percentage</td><td>The average percentage of this task's offset commit attempts that failed.</td></tr>
+<tr>
+<td></td><td>offset-commit-max-time-ms</td><td>The maximum time in milliseconds taken by this task to commit offsets.</td></tr>
+<tr>
+<td></td><td>offset-commit-success-percentage</td><td>The average percentage of this task's offset commit attempts that succeeded.</td></tr>
+<tr>
+<td></td><td>pause-ratio</td><td>The fraction of time this task has spent in the pause state.</td></tr>
+<tr>
+<td></td><td>running-ratio</td><td>The fraction of time this task has spent in the running state.</td></tr>
+<tr>
+<td></td><td>status</td><td>The status of the connector task. One of 'unassigned', 'running', 'paused', 'failed', or 'destroyed'.</td></tr>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.connect:type=sink-task-metrics,connector="{connector}",task="{task}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>offset-commit-completion-rate</td><td>The average per-second number of offset commit completions that were completed successfully.</td></tr>
+<tr>
+<td></td><td>offset-commit-completion-total</td><td>The total number of offset commit completions that were completed successfully.</td></tr>
+<tr>
+<td></td><td>offset-commit-seq-no</td><td>The current sequence number for offset commits.</td></tr>
+<tr>
+<td></td><td>offset-commit-skip-rate</td><td>The average per-second number of offset commit completions that were received too late and skipped/ignored.</td></tr>
+<tr>
+<td></td><td>offset-commit-skip-total</td><td>The total number of offset commit completions that were received too late and skipped/ignored.</td></tr>
+<tr>
+<td></td><td>partition-count</td><td>The number of topic partitions assigned to this task belonging to the named sink connector in this worker.</td></tr>
+<tr>
+<td></td><td>put-batch-avg-time-ms</td><td>The average time taken by this task to put a batch of sinks records.</td></tr>
+<tr>
+<td></td><td>put-batch-max-time-ms</td><td>The maximum time taken by this task to put a batch of sinks records.</td></tr>
+<tr>
+<td></td><td>sink-record-active-count</td><td>The number of records that have been read from Kafka but not yet completely committed/flushed/acknowledged by the sink task.</td></tr>
+<tr>
+<td></td><td>sink-record-active-count-avg</td><td>The average number of records that have been read from Kafka but not yet completely committed/flushed/acknowledged by the sink task.</td></tr>
+<tr>
+<td></td><td>sink-record-active-count-max</td><td>The maximum number of records that have been read from Kafka but not yet completely committed/flushed/acknowledged by the sink task.</td></tr>
+<tr>
+<td></td><td>sink-record-lag-max</td><td>The maximum lag in terms of number of records that the sink task is behind the consumer's position for any topic partitions.</td></tr>
+<tr>
+<td></td><td>sink-record-read-rate</td><td>The average per-second number of records read from Kafka for this task belonging to the named sink connector in this worker. This is before transformations are applied.</td></tr>
+<tr>
+<td></td><td>sink-record-read-total</td><td>The total number of records read from Kafka by this task belonging to the named sink connector in this worker, since the task was last restarted.</td></tr>
+<tr>
+<td></td><td>sink-record-send-rate</td><td>The average per-second number of records output from the transformations and sent/put to this task belonging to the named sink connector in this worker. This is after transformations are applied and excludes any records filtered out by the transformations.</td></tr>
+<tr>
+<td></td><td>sink-record-send-total</td><td>The total number of records output from the transformations and sent/put to this task belonging to the named sink connector in this worker, since the task was last restarted.</td></tr>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.connect:type=source-task-metrics,connector="{connector}",task="{task}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>poll-batch-avg-time-ms</td><td>The average time in milliseconds taken by this task to poll for a batch of source records.</td></tr>
+<tr>
+<td></td><td>poll-batch-max-time-ms</td><td>The maximum time in milliseconds taken by this task to poll for a batch of source records.</td></tr>
+<tr>
+<td></td><td>source-record-active-count</td><td>The number of records that have been produced by this task but not yet completely written to Kafka.</td></tr>
+<tr>
+<td></td><td>source-record-active-count-avg</td><td>The average number of records that have been produced by this task but not yet completely written to Kafka.</td></tr>
+<tr>
+<td></td><td>source-record-active-count-max</td><td>The maximum number of records that have been produced by this task but not yet completely written to Kafka.</td></tr>
+<tr>
+<td></td><td>source-record-poll-rate</td><td>The average per-second number of records produced/polled (before transformation) by this task belonging to the named source connector in this worker.</td></tr>
+<tr>
+<td></td><td>source-record-poll-total</td><td>The total number of records produced/polled (before transformation) by this task belonging to the named source connector in this worker.</td></tr>
+<tr>
+<td></td><td>source-record-write-rate</td><td>The average per-second number of records output from the transformations and written to Kafka for this task belonging to the named source connector in this worker. This is after transformations are applied and excludes any records filtered out by the transformations.</td></tr>
+<tr>
+<td></td><td>source-record-write-total</td><td>The number of records output from the transformations and written to Kafka for this task belonging to the named source connector in this worker, since the task was last restarted.</td></tr>
+</tbody></table>
diff --git a/11/generated/connect_transforms.html b/11/generated/connect_transforms.html
new file mode 100644
index 0000000..452ab01
--- /dev/null
+++ b/11/generated/connect_transforms.html
@@ -0,0 +1,228 @@
+<div id="org.apache.kafka.connect.transforms.InsertField">
+<h5>org.apache.kafka.connect.transforms.InsertField</h5>
+Insert field(s) using attributes from the record metadata or a configured static value.<p/>Use the concrete transformation type designed for the record key (<code>org.apache.kafka.connect.transforms.InsertField$Key</code>) or value (<code>org.apache.kafka.connect.transforms.InsertField$Value</code>).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>offset.field</td></td><td>Field name for Kafka offset - only applicable to sink connectors.<br/>Suffix with <code>!</code> to make this a required field, or <code>?</code> to keep it optional (the default).</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>partition.field</td></td><td>Field name for Kafka partition. Suffix with <code>!</code> to make this a required field, or <code>?</code> to keep it optional (the default).</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>static.field</td></td><td>Field name for static data field. Suffix with <code>!</code> to make this a required field, or <code>?</code> to keep it optional (the default).</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>static.value</td></td><td>Static field value, if field name configured.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>timestamp.field</td></td><td>Field name for record timestamp. Suffix with <code>!</code> to make this a required field, or <code>?</code> to keep it optional (the default).</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>topic.field</td></td><td>Field name for Kafka topic. Suffix with <code>!</code> to make this a required field, or <code>?</code> to keep it optional (the default).</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.ReplaceField">
+<h5>org.apache.kafka.connect.transforms.ReplaceField</h5>
+Filter or rename fields.<p/>Use the concrete transformation type designed for the record key (<code>org.apache.kafka.connect.transforms.ReplaceField$Key</code>) or value (<code>org.apache.kafka.connect.transforms.ReplaceField$Value</code>).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>blacklist</td></td><td>Fields to exclude. This takes precedence over the whitelist.</td></td><td>list</td></td><td>""</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>renames</td></td><td>Field rename mappings.</td></td><td>list</td></td><td>""</td></td><td>list of colon-delimited pairs, e.g. <code>foo:bar,abc:xyz</code></td></td><td>medium</td></td></tr>
+<tr>
+<td>whitelist</td></td><td>Fields to include. If specified, only these fields will be used.</td></td><td>list</td></td><td>""</td></td><td></td></td><td>medium</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.MaskField">
+<h5>org.apache.kafka.connect.transforms.MaskField</h5>
+Mask specified fields with a valid null value for the field type (i.e. 0, false, empty string, and so on).<p/>Use the concrete transformation type designed for the record key (<code>org.apache.kafka.connect.transforms.MaskField$Key</code>) or value (<code>org.apache.kafka.connect.transforms.MaskField$Value</code>).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>fields</td></td><td>Names of fields to mask.</td></td><td>list</td></td><td></td></td><td>non-empty list</td></td><td>high</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.ValueToKey">
+<h5>org.apache.kafka.connect.transforms.ValueToKey</h5>
+Replace the record key with a new key formed from a subset of fields in the record value.
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>fields</td></td><td>Field names on the record value to extract as the record key.</td></td><td>list</td></td><td></td></td><td>non-empty list</td></td><td>high</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.HoistField">
+<h5>org.apache.kafka.connect.transforms.HoistField</h5>
+Wrap data using the specified field name in a Struct when schema present, or a Map in the case of schemaless data.<p/>Use the concrete transformation type designed for the record key (<code>org.apache.kafka.connect.transforms.HoistField$Key</code>) or value (<code>org.apache.kafka.connect.transforms.HoistField$Value</code>).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>field</td></td><td>Field name for the single field that will be created in the resulting Struct or Map.</td></td><td>string</td></td><td></td></td><td></td></td><td>medium</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.ExtractField">
+<h5>org.apache.kafka.connect.transforms.ExtractField</h5>
+Extract the specified field from a Struct when schema present, or a Map in the case of schemaless data. Any null values are passed through unmodified.<p/>Use the concrete transformation type designed for the record key (<code>org.apache.kafka.connect.transforms.ExtractField$Key</code>) or value (<code>org.apache.kafka.connect.transforms.ExtractField$Value</code>).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>field</td></td><td>Field name to extract.</td></td><td>string</td></td><td></td></td><td></td></td><td>medium</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.SetSchemaMetadata">
+<h5>org.apache.kafka.connect.transforms.SetSchemaMetadata</h5>
+Set the schema name, version or both on the record's key (<code>org.apache.kafka.connect.transforms.SetSchemaMetadata$Key</code>) or value (<code>org.apache.kafka.connect.transforms.SetSchemaMetadata$Value</code>) schema.
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>schema.name</td></td><td>Schema name to set.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>schema.version</td></td><td>Schema version to set.</td></td><td>int</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.TimestampRouter">
+<h5>org.apache.kafka.connect.transforms.TimestampRouter</h5>
+Update the record's topic field as a function of the original topic value and the record timestamp.<p/>This is mainly useful for sink connectors, since the topic field is often used to determine the equivalent entity name in the destination system(e.g. database table or search index name).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>timestamp.format</td></td><td>Format string for the timestamp that is compatible with <code>java.text.SimpleDateFormat</code>.</td></td><td>string</td></td><td>yyyyMMdd</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>topic.format</td></td><td>Format string which can contain <code>${topic}</code> and <code>${timestamp}</code> as placeholders for the topic and timestamp, respectively.</td></td><td>string</td></td><td>${topic}-${timestamp}</td></td><td></td></td><td>high</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.RegexRouter">
+<h5>org.apache.kafka.connect.transforms.RegexRouter</h5>
+Update the record topic using the configured regular expression and replacement string.<p/>Under the hood, the regex is compiled to a <code>java.util.regex.Pattern</code>. If the pattern matches the input topic, <code>java.util.regex.Matcher#replaceFirst()</code> is used with the replacement string to obtain the new topic.
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>regex</td></td><td>Regular expression to use for matching.</td></td><td>string</td></td><td></td></td><td>valid regex</td></td><td>high</td></td></tr>
+<tr>
+<td>replacement</td></td><td>Replacement string.</td></td><td>string</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.Flatten">
+<h5>org.apache.kafka.connect.transforms.Flatten</h5>
+Flatten a nested data structure, generating names for each field by concatenating the field names at each level with a configurable delimiter character. Applies to Struct when schema present, or a Map in the case of schemaless data. The default delimiter is '.'.<p/>Use the concrete transformation type designed for the record key (<code>org.apache.kafka.connect.transforms.Flatten$Key</code>) or value (<code>org.apache.kafka.connect.transforms.Flatten$Value</code>).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>delimiter</td></td><td>Delimiter to insert between field names from the input record when generating field names for the output record</td></td><td>string</td></td><td>.</td></td><td></td></td><td>medium</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.Cast">
+<h5>org.apache.kafka.connect.transforms.Cast</h5>
+Cast fields or the entire key or value to a specific type, e.g. to force an integer field to a smaller width. Only simple primitive types are supported -- integers, floats, boolean, and string. <p/>Use the concrete transformation type designed for the record key (<code>org.apache.kafka.connect.transforms.Cast$Key</code>) or value (<code>org.apache.kafka.connect.transforms.Cast$Value</code>).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>spec</td></td><td>List of fields and the type to cast them to of the form field1:type,field2:type to cast fields of Maps or Structs. A single type to cast the entire value. Valid types are int8, int16, int32, int64, float32, float64, boolean, and string.</td></td><td>list</td></td><td></td></td><td>list of colon-delimited pairs, e.g. <code>foo:bar,abc:xyz</code></td></td><td>high</td></td></tr>
+</tbody></table>
+</div>
+<div id="org.apache.kafka.connect.transforms.TimestampConverter">
+<h5>org.apache.kafka.connect.transforms.TimestampConverter</h5>
+Convert timestamps between different formats such as Unix epoch, strings, and Connect Date/Timestamp types.Applies to individual fields or to the entire value.<p/>Use the concrete transformation type designed for the record key (<code>org.apache.kafka.connect.transforms.TimestampConverter$Key</code>) or value (<code>org.apache.kafka.connect.transforms.TimestampConverter$Value</code>).
+<p/>
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>target.type</td></td><td>The desired timestamp representation: string, unix, Date, Time, or Timestamp</td></td><td>string</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>field</td></td><td>The field containing the timestamp, or empty if the entire value is a timestamp</td></td><td>string</td></td><td>""</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>format</td></td><td>A SimpleDateFormat-compatible format for the timestamp. Used to generate the output when type=string or used to parse the input if the input is a string.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>medium</td></td></tr>
+</tbody></table>
+</div>
diff --git a/11/generated/consumer_config.html b/11/generated/consumer_config.html
new file mode 100644
index 0000000..8217753
--- /dev/null
+++ b/11/generated/consumer_config.html
@@ -0,0 +1,122 @@
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>key.deserializer</td></td><td>Deserializer class for key that implements the <code>org.apache.kafka.common.serialization.Deserializer</code> interface.</td></td><td>class</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>value.deserializer</td></td><td>Deserializer class for value that implements the <code>org.apache.kafka.common.serialization.Deserializer</code> interface.</td></td><td>class</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>bootstrap.servers</td></td><td>A list of host/port pairs to use for establishing the initial connection to the Kafka cluster. The client will make use of all servers irrespective of which servers are specified here for bootstrapping—this list only impacts the initial hosts used to discover the full set of servers. This list should be in the form <code>host1:port1,host2:port2,...</code>. Since these servers are just used for the initial connection to discover the full cluster me [...]
+<tr>
+<td>fetch.min.bytes</td></td><td>The minimum amount of data the server should return for a fetch request. If insufficient data is available the request will wait for that much data to accumulate before answering the request. The default setting of 1 byte means that fetch requests are answered as soon as a single byte of data is available or the fetch request times out waiting for data to arrive. Setting this to something greater than 1 will cause the server to wait for larger amounts of [...]
+<tr>
+<td>group.id</td></td><td>A unique string that identifies the consumer group this consumer belongs to. This property is required if the consumer uses either the group management functionality by using <code>subscribe(topic)</code> or the Kafka-based offset management strategy.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>heartbeat.interval.ms</td></td><td>The expected time between heartbeats to the consumer coordinator when using Kafka's group management facilities. Heartbeats are used to ensure that the consumer's session stays active and to facilitate rebalancing when new consumers join or leave the group. The value must be set lower than <code>session.timeout.ms</code>, but typically should be set no higher than 1/3 of that value. It can be adjusted even lower to control the expected time for norm [...]
+<tr>
+<td>max.partition.fetch.bytes</td></td><td>The maximum amount of data per-partition the server will return. Records are fetched in batches by the consumer. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch will still be returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined via <code>message.max.bytes</code> (broker config) or <code>max.message.bytes</code> (topic c [...]
+<tr>
+<td>session.timeout.ms</td></td><td>The timeout used to detect consumer failures when using Kafka's group management facility. The consumer sends periodic heartbeats to indicate its liveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker will remove this consumer from the group and initiate a rebalance. Note that the value must be in the allowable range as configured in the broker configuration by <code>group.min. [...]
+<tr>
+<td>ssl.key.password</td></td><td>The password of the private key in the key store file. This is optional for client.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.keystore.location</td></td><td>The location of the key store file. This is optional for client and can be used for two-way authentication for client.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.keystore.password</td></td><td>The store password for the key store file. This is optional for client and only needed if ssl.keystore.location is configured. </td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.truststore.location</td></td><td>The location of the trust store file. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.truststore.password</td></td><td>The password for the trust store file. If a password is not set access to the truststore is still available, but integrity checking is disabled.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>auto.offset.reset</td></td><td>What to do when there is no initial offset in Kafka or if the current offset does not exist any more on the server (e.g. because that data has been deleted): <ul><li>earliest: automatically reset the offset to the earliest offset<li>latest: automatically reset the offset to the latest offset</li><li>none: throw exception to the consumer if no previous offset is found for the consumer's group</li><li>anything else: throw exception to the consumer.</li></ [...]
+<tr>
+<td>connections.max.idle.ms</td></td><td>Close idle connections after the number of milliseconds specified by this config.</td></td><td>long</td></td><td>540000</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>enable.auto.commit</td></td><td>If true the consumer's offset will be periodically committed in the background.</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>exclude.internal.topics</td></td><td>Whether records from internal topics (such as offsets) should be exposed to the consumer. If set to <code>true</code> the only way to receive records from an internal topic is subscribing to it.</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>fetch.max.bytes</td></td><td>The maximum amount of data the server should return for a fetch request. Records are fetched in batches by the consumer, and if the first record batch in the first non-empty partition of the fetch is larger than this value, the record batch will still be returned to ensure that the consumer can make progress. As such, this is not a absolute maximum. The maximum record batch size accepted by the broker is defined via <code>message.max.bytes</code> (broker [...]
+<tr>
+<td>isolation.level</td></td><td><p>Controls how to read messages written transactionally. If set to <code>read_committed</code>, consumer.poll() will only return transactional messages which have been committed. If set to <code>read_uncommitted</code>' (the default), consumer.poll() will return all messages, even transactional messages which have been aborted. Non-transactional messages will be returned unconditionally in either mode.</p> <p>Messages will always be returned in offset or [...]
+<tr>
+<td>max.poll.interval.ms</td></td><td>The maximum delay between invocations of poll() when using consumer group management. This places an upper bound on the amount of time that the consumer can be idle before fetching more records. If poll() is not called before expiration of this timeout, then the consumer is considered failed and the group will rebalance in order to reassign the partitions to another member. </td></td><td>int</td></td><td>300000</td></td><td>[1,...]</td></td><td>mediu [...]
+<tr>
+<td>max.poll.records</td></td><td>The maximum number of records returned in a single call to poll().</td></td><td>int</td></td><td>500</td></td><td>[1,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>partition.assignment.strategy</td></td><td>The class name of the partition assignment strategy that the client will use to distribute partition ownership amongst consumer instances when group management is used</td></td><td>list</td></td><td>class org.apache.kafka.clients.consumer.RangeAssignor</td></td><td>org.apache.kafka.common.config.ConfigDef$NonNullValidator@3c80d0bb</td></td><td>medium</td></td></tr>
+<tr>
+<td>receive.buffer.bytes</td></td><td>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>65536</td></td><td>[-1,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>request.timeout.ms</td></td><td>The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted.</td></td><td>int</td></td><td>305000</td></td><td>[0,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.jaas.config</td></td><td>JAAS login context parameters for SASL connections in the format used by JAAS configuration files. JAAS configuration file format is described <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/LoginConfigFile.html">here</a>. The format for the value is: '<loginModuleClass> <controlFlag> (<optionName>=<optionValue>)*;'</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.kerberos.service.name</td></td><td>The Kerberos principal name that Kafka runs as. This can be defined either in Kafka's JAAS config or in Kafka's config.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.mechanism</td></td><td>SASL mechanism used for client connections. This may be any mechanism for which a security provider is available. GSSAPI is the default mechanism.</td></td><td>string</td></td><td>GSSAPI</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>security.protocol</td></td><td>Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.</td></td><td>string</td></td><td>PLAINTEXT</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>send.buffer.bytes</td></td><td>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>131072</td></td><td>[-1,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.enabled.protocols</td></td><td>The list of protocols enabled for SSL connections.</td></td><td>list</td></td><td>TLSv1.2,TLSv1.1,TLSv1</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.keystore.type</td></td><td>The file format of the key store file. This is optional for client.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.protocol</td></td><td>The SSL protocol used to generate the SSLContext. Default setting is TLS, which is fine for most cases. Allowed values in recent JVMs are TLS, TLSv1.1 and TLSv1.2. SSL, SSLv2 and SSLv3 may be supported in older JVMs, but their usage is discouraged due to known security vulnerabilities.</td></td><td>string</td></td><td>TLS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.provider</td></td><td>The name of the security provider used for SSL connections. Default value is the default security provider of the JVM.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.truststore.type</td></td><td>The file format of the trust store file.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>auto.commit.interval.ms</td></td><td>The frequency in milliseconds that the consumer offsets are auto-committed to Kafka if <code>enable.auto.commit</code> is set to <code>true</code>.</td></td><td>int</td></td><td>5000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>check.crcs</td></td><td>Automatically check the CRC32 of the records consumed. This ensures no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so it may be disabled in cases seeking extreme performance.</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>client.id</td></td><td>An id string to pass to the server when making requests. The purpose of this is to be able to track the source of requests beyond just ip/port by allowing a logical application name to be included in server-side request logging.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>fetch.max.wait.ms</td></td><td>The maximum amount of time the server will block before answering the fetch request if there isn't sufficient data to immediately satisfy the requirement given by fetch.min.bytes.</td></td><td>int</td></td><td>500</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>interceptor.classes</td></td><td>A list of classes to use as interceptors. Implementing the <code>org.apache.kafka.clients.consumer.ConsumerInterceptor</code> interface allows you to intercept (and possibly mutate) records received by the consumer. By default, there are no interceptors.</td></td><td>list</td></td><td>""</td></td><td>org.apache.kafka.common.config.ConfigDef$NonNullValidator@2d07c405</td></td><td>low</td></td></tr>
+<tr>
+<td>metadata.max.age.ms</td></td><td>The period of time in milliseconds after which we force a refresh of metadata even if we haven't seen any partition leadership changes to proactively discover any new brokers or partitions.</td></td><td>long</td></td><td>300000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metric.reporters</td></td><td>A list of classes to use as metrics reporters. Implementing the <code>org.apache.kafka.common.metrics.MetricsReporter</code> interface allows plugging in classes that will be notified of new metric creation. The JmxReporter is always included to register JMX statistics.</td></td><td>list</td></td><td>""</td></td><td>org.apache.kafka.common.config.ConfigDef$NonNullValidator@58d63b5b</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.num.samples</td></td><td>The number of samples maintained to compute metrics.</td></td><td>int</td></td><td>2</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.recording.level</td></td><td>The highest recording level for metrics.</td></td><td>string</td></td><td>INFO</td></td><td>[INFO, DEBUG]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.sample.window.ms</td></td><td>The window of time a metrics sample is computed over.</td></td><td>long</td></td><td>30000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.max.ms</td></td><td>The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.</td></td><td>long</td></td><td>1000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.ms</td></td><td>The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker.</td></td><td>long</td></td><td>50</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>retry.backoff.ms</td></td><td>The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios.</td></td><td>long</td></td><td>100</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.kinit.cmd</td></td><td>Kerberos kinit command path.</td></td><td>string</td></td><td>/usr/bin/kinit</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.min.time.before.relogin</td></td><td>Login thread sleep time between refresh attempts.</td></td><td>long</td></td><td>60000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.jitter</td></td><td>Percentage of random jitter added to the renewal time.</td></td><td>double</td></td><td>0.05</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.window.factor</td></td><td>Login thread will sleep until the specified window factor of time from last refresh to ticket's expiry has been reached, at which time it will try to renew the ticket.</td></td><td>double</td></td><td>0.8</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.cipher.suites</td></td><td>A list of cipher suites. This is a named combination of authentication, encryption, MAC and key exchange algorithm used to negotiate the security settings for a network connection using TLS or SSL network protocol. By default all the available cipher suites are supported.</td></td><td>list</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.endpoint.identification.algorithm</td></td><td>The endpoint identification algorithm to validate server hostname using server certificate. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.keymanager.algorithm</td></td><td>The algorithm used by key manager factory for SSL connections. Default value is the key manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>SunX509</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.secure.random.implementation</td></td><td>The SecureRandom PRNG implementation to use for SSL cryptography operations. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.trustmanager.algorithm</td></td><td>The algorithm used by trust manager factory for SSL connections. Default value is the trust manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>PKIX</td></td><td></td></td><td>low</td></td></tr>
+</tbody></table>
diff --git a/11/generated/consumer_metrics.html b/11/generated/consumer_metrics.html
new file mode 100644
index 0000000..6131d76
--- /dev/null
+++ b/11/generated/consumer_metrics.html
@@ -0,0 +1,77 @@
+<table class="data-table"><tbody>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.consumer:type=consumer-fetch-manager-metrics,client-id="{client-id}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>bytes-consumed-rate</td><td>The average number of bytes consumed per second</td></tr>
+<tr>
+<td></td><td>bytes-consumed-total</td><td>The total number of bytes consumed</td></tr>
+<tr>
+<td></td><td>fetch-latency-avg</td><td>The average time taken for a fetch request.</td></tr>
+<tr>
+<td></td><td>fetch-latency-max</td><td>The max time taken for any fetch request.</td></tr>
+<tr>
+<td></td><td>fetch-rate</td><td>The number of fetch requests per second.</td></tr>
+<tr>
+<td></td><td>fetch-size-avg</td><td>The average number of bytes fetched per request</td></tr>
+<tr>
+<td></td><td>fetch-size-max</td><td>The maximum number of bytes fetched per request</td></tr>
+<tr>
+<td></td><td>fetch-throttle-time-avg</td><td>The average throttle time in ms</td></tr>
+<tr>
+<td></td><td>fetch-throttle-time-max</td><td>The maximum throttle time in ms</td></tr>
+<tr>
+<td></td><td>fetch-total</td><td>The total number of fetch requests.</td></tr>
+<tr>
+<td></td><td>records-consumed-rate</td><td>The average number of records consumed per second</td></tr>
+<tr>
+<td></td><td>records-consumed-total</td><td>The total number of records consumed</td></tr>
+<tr>
+<td></td><td>records-lag-max</td><td>The maximum lag in terms of number of records for any partition in this window</td></tr>
+<tr>
+<td></td><td>records-per-request-avg</td><td>The average number of records in each request</td></tr>
+<tr>
+<td></td><td>{topic}-{partition}.records-lag</td><td>The latest lag of the partition (DEPRECATED use the tag based version instead)</td></tr>
+<tr>
+<td></td><td>{topic}-{partition}.records-lag-avg</td><td>The average lag of the partition (DEPRECATED use the tag based version instead)</td></tr>
+<tr>
+<td></td><td>{topic}-{partition}.records-lag-max</td><td>The max lag of the partition (DEPRECATED use the tag based version instead)</td></tr>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.consumer:type=consumer-fetch-manager-metrics,client-id="{client-id}",topic="{topic}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>bytes-consumed-rate</td><td>The average number of bytes consumed per second for a topic</td></tr>
+<tr>
+<td></td><td>bytes-consumed-total</td><td>The total number of bytes consumed for a topic</td></tr>
+<tr>
+<td></td><td>fetch-size-avg</td><td>The average number of bytes fetched per request for a topic</td></tr>
+<tr>
+<td></td><td>fetch-size-max</td><td>The maximum number of bytes fetched per request for a topic</td></tr>
+<tr>
+<td></td><td>records-consumed-rate</td><td>The average number of records consumed per second for a topic</td></tr>
+<tr>
+<td></td><td>records-consumed-total</td><td>The total number of records consumed for a topic</td></tr>
+<tr>
+<td></td><td>records-per-request-avg</td><td>The average number of records in each request for a topic</td></tr>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.consumer:type=consumer-fetch-manager-metrics,topic="{topic}",partition="{partition}",client-id="{client-id}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>records-lag</td><td>The latest lag of the partition</td></tr>
+<tr>
+<td></td><td>records-lag-avg</td><td>The average lag of the partition</td></tr>
+<tr>
+<td></td><td>records-lag-max</td><td>The max lag of the partition</td></tr>
+</tbody></table>
diff --git a/11/generated/kafka_config.html b/11/generated/kafka_config.html
new file mode 100644
index 0000000..8539958
--- /dev/null
+++ b/11/generated/kafka_config.html
@@ -0,0 +1,365 @@
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+<th>Dynamic Update Mode</th>
+</tr>
+<tr>
+<td>zookeeper.connect</td></td><td>Zookeeper host string</td></td><td>string</td></td><td></td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>advertised.host.name</td></td><td>DEPRECATED: only used when `advertised.listeners` or `listeners` are not set. Use `advertised.listeners` instead.
+Hostname to publish to ZooKeeper for clients to use. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, it will use the value for `host.name` if configured. Otherwise it will use the value returned from java.net.InetAddress.getCanonicalHostName().</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>advertised.listeners</td></td><td>Listeners to publish to ZooKeeper for clients to use, if different than the `listeners` config property. In IaaS environments, this may need to be different from the interface to which the broker binds. If this is not set, the value for `listeners` will be used. Unlike `listeners` it is not valid to advertise the 0.0.0.0 meta-address.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td><td>per-broker</td></tr>
+<tr>
+<td>advertised.port</td></td><td>DEPRECATED: only used when `advertised.listeners` or `listeners` are not set. Use `advertised.listeners` instead.
+The port to publish to ZooKeeper for clients to use. In IaaS environments, this may need to be different from the port to which the broker binds. If this is not set, it will publish the same port that the broker binds to.</td></td><td>int</td></td><td>null</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>auto.create.topics.enable</td></td><td>Enable auto creation of topic on the server</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>auto.leader.rebalance.enable</td></td><td>Enables auto leader balancing. A background thread checks and triggers leader balance if required at regular intervals</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>background.threads</td></td><td>The number of threads to use for various background processing tasks</td></td><td>int</td></td><td>10</td></td><td>[1,...]</td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>broker.id</td></td><td>The broker id for this server. If unset, a unique broker id will be generated.To avoid conflicts between zookeeper generated broker id's and user configured broker id's, generated broker ids start from reserved.broker.max.id + 1.</td></td><td>int</td></td><td>-1</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>compression.type</td></td><td>Specify the final compression type for a given topic. This configuration accepts the standard compression codecs ('gzip', 'snappy', 'lz4'). It additionally accepts 'uncompressed' which is equivalent to no compression; and 'producer' which means retain the original compression codec set by the producer.</td></td><td>string</td></td><td>producer</td></td><td></td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>delete.topic.enable</td></td><td>Enables delete topic. Delete topic through the admin tool will have no effect if this config is turned off</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>host.name</td></td><td>DEPRECATED: only used when `listeners` is not set. Use `listeners` instead.
+hostname of broker. If this is set, it will only bind to this address. If this is not set, it will bind to all interfaces</td></td><td>string</td></td><td>""</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>leader.imbalance.check.interval.seconds</td></td><td>The frequency with which the partition rebalance check is triggered by the controller</td></td><td>long</td></td><td>300</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>leader.imbalance.per.broker.percentage</td></td><td>The ratio of leader imbalance allowed per broker. The controller would trigger a leader balance if it goes above this value per broker. The value is specified in percentage.</td></td><td>int</td></td><td>10</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>listeners</td></td><td>Listener List - Comma-separated list of URIs we will listen on and the listener names. If the listener name is not a security protocol, listener.security.protocol.map must also be set.
+ Specify hostname as 0.0.0.0 to bind to all interfaces.
+ Leave hostname empty to bind to default interface.
+ Examples of legal listener lists:
+ PLAINTEXT://myhost:9092,SSL://:9091
+ CLIENT://0.0.0.0:9092,REPLICATION://localhost:9093
+</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td><td>per-broker</td></tr>
+<tr>
+<td>log.dir</td></td><td>The directory in which the log data is kept (supplemental for log.dirs property)</td></td><td>string</td></td><td>/tmp/kafka-logs</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.dirs</td></td><td>The directories in which the log data is kept. If not set, the value in log.dir is used</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.flush.interval.messages</td></td><td>The number of messages accumulated on a log partition before messages are flushed to disk </td></td><td>long</td></td><td>9223372036854775807</td></td><td>[1,...]</td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.flush.interval.ms</td></td><td>The maximum time in ms that a message in any topic is kept in memory before flushed to disk. If not set, the value in log.flush.scheduler.interval.ms is used</td></td><td>long</td></td><td>null</td></td><td></td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.flush.offset.checkpoint.interval.ms</td></td><td>The frequency with which we update the persistent record of the last flush which acts as the log recovery point</td></td><td>int</td></td><td>60000</td></td><td>[0,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.flush.scheduler.interval.ms</td></td><td>The frequency in ms that the log flusher checks whether any log needs to be flushed to disk</td></td><td>long</td></td><td>9223372036854775807</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.flush.start.offset.checkpoint.interval.ms</td></td><td>The frequency with which we update the persistent record of log start offset</td></td><td>int</td></td><td>60000</td></td><td>[0,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.retention.bytes</td></td><td>The maximum size of the log before deleting it</td></td><td>long</td></td><td>-1</td></td><td></td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.retention.hours</td></td><td>The number of hours to keep a log file before deleting it (in hours), tertiary to log.retention.ms property</td></td><td>int</td></td><td>168</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.retention.minutes</td></td><td>The number of minutes to keep a log file before deleting it (in minutes), secondary to log.retention.ms property. If not set, the value in log.retention.hours is used</td></td><td>int</td></td><td>null</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.retention.ms</td></td><td>The number of milliseconds to keep a log file before deleting it (in milliseconds), If not set, the value in log.retention.minutes is used</td></td><td>long</td></td><td>null</td></td><td></td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.roll.hours</td></td><td>The maximum time before a new log segment is rolled out (in hours), secondary to log.roll.ms property</td></td><td>int</td></td><td>168</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.roll.jitter.hours</td></td><td>The maximum jitter to subtract from logRollTimeMillis (in hours), secondary to log.roll.jitter.ms property</td></td><td>int</td></td><td>0</td></td><td>[0,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>log.roll.jitter.ms</td></td><td>The maximum jitter to subtract from logRollTimeMillis (in milliseconds). If not set, the value in log.roll.jitter.hours is used</td></td><td>long</td></td><td>null</td></td><td></td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.roll.ms</td></td><td>The maximum time before a new log segment is rolled out (in milliseconds). If not set, the value in log.roll.hours is used</td></td><td>long</td></td><td>null</td></td><td></td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.segment.bytes</td></td><td>The maximum size of a single log file</td></td><td>int</td></td><td>1073741824</td></td><td>[14,...]</td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.segment.delete.delay.ms</td></td><td>The amount of time to wait before deleting a file from the filesystem</td></td><td>long</td></td><td>60000</td></td><td>[0,...]</td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>message.max.bytes</td></td><td><p>The largest record batch size allowed by Kafka. If this is increased and there are consumers older than 0.10.2, the consumers' fetch size must also be increased so that the they can fetch record batches this large.</p><p>In the latest message format version, records are always grouped into batches for efficiency. In previous message format versions, uncompressed records are not grouped into batches and this limit only applies to a single record in th [...]
+<tr>
+<td>min.insync.replicas</td></td><td>When a producer sets acks to "all" (or "-1"), min.insync.replicas specifies the minimum number of replicas that must acknowledge a write for the write to be considered successful. If this minimum cannot be met, then the producer will raise an exception (either NotEnoughReplicas or NotEnoughReplicasAfterAppend).<br>When used together, min.insync.replicas and acks allow you to enforce greater durability guarantees. A typical scenario would be to create [...]
+<tr>
+<td>num.io.threads</td></td><td>The number of threads that the server uses for processing requests, which may include disk I/O</td></td><td>int</td></td><td>8</td></td><td>[1,...]</td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>num.network.threads</td></td><td>The number of threads that the server uses for receiving requests from the network and sending responses to the network</td></td><td>int</td></td><td>3</td></td><td>[1,...]</td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>num.recovery.threads.per.data.dir</td></td><td>The number of threads per data directory to be used for log recovery at startup and flushing at shutdown</td></td><td>int</td></td><td>1</td></td><td>[1,...]</td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>num.replica.alter.log.dirs.threads</td></td><td>The number of threads that can move replicas between log directories, which may include disk I/O</td></td><td>int</td></td><td>null</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>num.replica.fetchers</td></td><td>Number of fetcher threads used to replicate messages from a source broker. Increasing this value can increase the degree of I/O parallelism in the follower broker.</td></td><td>int</td></td><td>1</td></td><td></td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>offset.metadata.max.bytes</td></td><td>The maximum size for a metadata entry associated with an offset commit</td></td><td>int</td></td><td>4096</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.commit.required.acks</td></td><td>The required acks before the commit can be accepted. In general, the default (-1) should not be overridden</td></td><td>short</td></td><td>-1</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.commit.timeout.ms</td></td><td>Offset commit will be delayed until all replicas for the offsets topic receive the commit or this timeout is reached. This is similar to the producer request timeout.</td></td><td>int</td></td><td>5000</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.load.buffer.size</td></td><td>Batch size for reading from the offsets segments when loading offsets into the cache.</td></td><td>int</td></td><td>5242880</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.retention.check.interval.ms</td></td><td>Frequency at which to check for stale offsets</td></td><td>long</td></td><td>600000</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.retention.minutes</td></td><td>Offsets older than this retention period will be discarded</td></td><td>int</td></td><td>1440</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.topic.compression.codec</td></td><td>Compression codec for the offsets topic - compression may be used to achieve "atomic" commits</td></td><td>int</td></td><td>0</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.topic.num.partitions</td></td><td>The number of partitions for the offset commit topic (should not change after deployment)</td></td><td>int</td></td><td>50</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.topic.replication.factor</td></td><td>The replication factor for the offsets topic (set higher to ensure availability). Internal topic creation will fail until the cluster size meets this replication factor requirement.</td></td><td>short</td></td><td>3</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>offsets.topic.segment.bytes</td></td><td>The offsets topic segment bytes should be kept relatively small in order to facilitate faster log compaction and cache loads</td></td><td>int</td></td><td>104857600</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>port</td></td><td>DEPRECATED: only used when `listeners` is not set. Use `listeners` instead.
+the port to listen and accept connections on</td></td><td>int</td></td><td>9092</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>queued.max.requests</td></td><td>The number of queued requests allowed before blocking the network threads</td></td><td>int</td></td><td>500</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>quota.consumer.default</td></td><td>DEPRECATED: Used only when dynamic default quotas are not configured for <user, <client-id> or <user, client-id> in Zookeeper. Any consumer distinguished by clientId/consumer group will get throttled if it fetches more bytes than this value per-second</td></td><td>long</td></td><td>9223372036854775807</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>quota.producer.default</td></td><td>DEPRECATED: Used only when dynamic default quotas are not configured for <user>, <client-id> or <user, client-id> in Zookeeper. Any producer distinguished by clientId will get throttled if it produces more bytes than this value per-second</td></td><td>long</td></td><td>9223372036854775807</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>replica.fetch.min.bytes</td></td><td>Minimum bytes expected for each fetch response. If not enough bytes, wait up to replicaMaxWaitTimeMs</td></td><td>int</td></td><td>1</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>replica.fetch.wait.max.ms</td></td><td>max wait time for each fetcher request issued by follower replicas. This value should always be less than the replica.lag.time.max.ms at all times to prevent frequent shrinking of ISR for low throughput topics</td></td><td>int</td></td><td>500</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>replica.high.watermark.checkpoint.interval.ms</td></td><td>The frequency with which the high watermark is saved out to disk</td></td><td>long</td></td><td>5000</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>replica.lag.time.max.ms</td></td><td>If a follower hasn't sent any fetch requests or hasn't consumed up to the leaders log end offset for at least this time, the leader will remove the follower from isr</td></td><td>long</td></td><td>10000</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>replica.socket.receive.buffer.bytes</td></td><td>The socket receive buffer for network requests</td></td><td>int</td></td><td>65536</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>replica.socket.timeout.ms</td></td><td>The socket timeout for network requests. Its value should be at least replica.fetch.wait.max.ms</td></td><td>int</td></td><td>30000</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>request.timeout.ms</td></td><td>The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted.</td></td><td>int</td></td><td>30000</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>socket.receive.buffer.bytes</td></td><td>The SO_RCVBUF buffer of the socket sever sockets. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>102400</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>socket.request.max.bytes</td></td><td>The maximum number of bytes in a socket request</td></td><td>int</td></td><td>104857600</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>socket.send.buffer.bytes</td></td><td>The SO_SNDBUF buffer of the socket sever sockets. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>102400</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>transaction.max.timeout.ms</td></td><td>The maximum allowed timeout for transactions. If a client’s requested transaction time exceed this, then the broker will return an error in InitProducerIdRequest. This prevents a client from too large of a timeout, which can stall consumers reading from topics included in the transaction.</td></td><td>int</td></td><td>900000</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>transaction.state.log.load.buffer.size</td></td><td>Batch size for reading from the transaction log segments when loading producer ids and transactions into the cache.</td></td><td>int</td></td><td>5242880</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>transaction.state.log.min.isr</td></td><td>Overridden min.insync.replicas config for the transaction topic.</td></td><td>int</td></td><td>2</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>transaction.state.log.num.partitions</td></td><td>The number of partitions for the transaction topic (should not change after deployment).</td></td><td>int</td></td><td>50</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>transaction.state.log.replication.factor</td></td><td>The replication factor for the transaction topic (set higher to ensure availability). Internal topic creation will fail until the cluster size meets this replication factor requirement.</td></td><td>short</td></td><td>3</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>transaction.state.log.segment.bytes</td></td><td>The transaction topic segment bytes should be kept relatively small in order to facilitate faster log compaction and cache loads</td></td><td>int</td></td><td>104857600</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>transactional.id.expiration.ms</td></td><td>The maximum amount of time in ms that the transaction coordinator will wait before proactively expire a producer's transactional id without receiving any transaction status updates from it.</td></td><td>int</td></td><td>604800000</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>unclean.leader.election.enable</td></td><td>Indicates whether to enable replicas not in the ISR set to be elected as leader as a last resort, even though doing so may result in data loss</td></td><td>boolean</td></td><td>false</td></td><td></td></td><td>high</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>zookeeper.connection.timeout.ms</td></td><td>The max time that the client waits to establish a connection to zookeeper. If not set, the value in zookeeper.session.timeout.ms is used</td></td><td>int</td></td><td>null</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>zookeeper.max.in.flight.requests</td></td><td>The maximum number of unacknowledged requests the client will send to Zookeeper before blocking.</td></td><td>int</td></td><td>10</td></td><td>[1,...]</td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>zookeeper.session.timeout.ms</td></td><td>Zookeeper session timeout</td></td><td>int</td></td><td>6000</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>zookeeper.set.acl</td></td><td>Set client to use secure ACLs</td></td><td>boolean</td></td><td>false</td></td><td></td></td><td>high</td></td><td>read-only</td></tr>
+<tr>
+<td>broker.id.generation.enable</td></td><td>Enable automatic broker id generation on the server. When enabled the value configured for reserved.broker.max.id should be reviewed.</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>broker.rack</td></td><td>Rack of the broker. This will be used in rack aware replication assignment for fault tolerance. Examples: `RACK1`, `us-east-1d`</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>connections.max.idle.ms</td></td><td>Idle connections timeout: the server socket processor threads close the connections that idle more than this</td></td><td>long</td></td><td>600000</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>controlled.shutdown.enable</td></td><td>Enable controlled shutdown of the server</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>controlled.shutdown.max.retries</td></td><td>Controlled shutdown can fail for multiple reasons. This determines the number of retries when such failure happens</td></td><td>int</td></td><td>3</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>controlled.shutdown.retry.backoff.ms</td></td><td>Before each retry, the system needs time to recover from the state that caused the previous failure (Controller fail over, replica lag etc). This config determines the amount of time to wait before retrying.</td></td><td>long</td></td><td>5000</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>controller.socket.timeout.ms</td></td><td>The socket timeout for controller-to-broker channels</td></td><td>int</td></td><td>30000</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>default.replication.factor</td></td><td>default replication factors for automatically created topics</td></td><td>int</td></td><td>1</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>delegation.token.expiry.time.ms</td></td><td>The token validity time in seconds before the token needs to be renewed. Default value 1 day.</td></td><td>long</td></td><td>86400000</td></td><td>[1,...]</td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>delegation.token.master.key</td></td><td>Master/secret key to generate and verify delegation tokens. Same key must be configured across all the brokers. If the key is not set or set to empty string, brokers will disable the delegation token support.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>delegation.token.max.lifetime.ms</td></td><td>The token has a maximum lifetime beyond which it cannot be renewed anymore. Default value 7 days.</td></td><td>long</td></td><td>604800000</td></td><td>[1,...]</td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>delete.records.purgatory.purge.interval.requests</td></td><td>The purge interval (in number of requests) of the delete records request purgatory</td></td><td>int</td></td><td>1</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>fetch.purgatory.purge.interval.requests</td></td><td>The purge interval (in number of requests) of the fetch request purgatory</td></td><td>int</td></td><td>1000</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>group.initial.rebalance.delay.ms</td></td><td>The amount of time the group coordinator will wait for more consumers to join a new group before performing the first rebalance. A longer delay means potentially fewer rebalances, but increases the time until processing begins.</td></td><td>int</td></td><td>3000</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>group.max.session.timeout.ms</td></td><td>The maximum allowed session timeout for registered consumers. Longer timeouts give consumers more time to process messages in between heartbeats at the cost of a longer time to detect failures.</td></td><td>int</td></td><td>300000</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>group.min.session.timeout.ms</td></td><td>The minimum allowed session timeout for registered consumers. Shorter timeouts result in quicker failure detection at the cost of more frequent consumer heartbeating, which can overwhelm broker resources.</td></td><td>int</td></td><td>6000</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>inter.broker.listener.name</td></td><td>Name of listener used for communication between brokers. If this is unset, the listener name is defined by security.inter.broker.protocol. It is an error to set this and security.inter.broker.protocol properties at the same time.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>inter.broker.protocol.version</td></td><td>Specify which version of the inter-broker protocol will be used.
+ This is typically bumped after all brokers were upgraded to a new version.
+ Example of some valid values are: 0.8.0, 0.8.1, 0.8.1.1, 0.8.2, 0.8.2.0, 0.8.2.1, 0.9.0.0, 0.9.0.1 Check ApiVersion for the full list.</td></td><td>string</td></td><td>1.1-IV0</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>log.cleaner.backoff.ms</td></td><td>The amount of time to sleep when there are no logs to clean</td></td><td>long</td></td><td>15000</td></td><td>[0,...]</td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleaner.dedupe.buffer.size</td></td><td>The total memory used for log deduplication across all cleaner threads</td></td><td>long</td></td><td>134217728</td></td><td></td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleaner.delete.retention.ms</td></td><td>How long are delete records retained?</td></td><td>long</td></td><td>86400000</td></td><td></td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleaner.enable</td></td><td>Enable the log cleaner process to run on the server. Should be enabled if using any topics with a cleanup.policy=compact including the internal offsets topic. If disabled those topics will not be compacted and continually grow in size.</td></td><td>boolean</td></td><td>true</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>log.cleaner.io.buffer.load.factor</td></td><td>Log cleaner dedupe buffer load factor. The percentage full the dedupe buffer can become. A higher value will allow more log to be cleaned at once but will lead to more hash collisions</td></td><td>double</td></td><td>0.9</td></td><td></td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleaner.io.buffer.size</td></td><td>The total memory used for log cleaner I/O buffers across all cleaner threads</td></td><td>int</td></td><td>524288</td></td><td>[0,...]</td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleaner.io.max.bytes.per.second</td></td><td>The log cleaner will be throttled so that the sum of its read and write i/o will be less than this value on average</td></td><td>double</td></td><td>1.7976931348623157E308</td></td><td></td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleaner.min.cleanable.ratio</td></td><td>The minimum ratio of dirty log to total log for a log to eligible for cleaning</td></td><td>double</td></td><td>0.5</td></td><td></td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleaner.min.compaction.lag.ms</td></td><td>The minimum time a message will remain uncompacted in the log. Only applicable for logs that are being compacted.</td></td><td>long</td></td><td>0</td></td><td></td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleaner.threads</td></td><td>The number of background threads to use for log cleaning</td></td><td>int</td></td><td>1</td></td><td>[0,...]</td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.cleanup.policy</td></td><td>The default cleanup policy for segments beyond the retention window. A comma separated list of valid policies. Valid policies are: "delete" and "compact"</td></td><td>list</td></td><td>delete</td></td><td>[compact, delete]</td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.index.interval.bytes</td></td><td>The interval with which we add an entry to the offset index</td></td><td>int</td></td><td>4096</td></td><td>[0,...]</td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.index.size.max.bytes</td></td><td>The maximum size in bytes of the offset index</td></td><td>int</td></td><td>10485760</td></td><td>[4,...]</td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.message.format.version</td></td><td>Specify the message format version the broker will use to append messages to the logs. The value should be a valid ApiVersion. Some examples are: 0.8.2, 0.9.0.0, 0.10.0, check ApiVersion for more details. By setting a particular message format version, the user is certifying that all the existing messages on disk are smaller or equal than the specified version. Setting this value incorrectly will cause consumers with older versions to break as [...]
+<tr>
+<td>log.message.timestamp.difference.max.ms</td></td><td>The maximum difference allowed between the timestamp when a broker receives a message and the timestamp specified in the message. If log.message.timestamp.type=CreateTime, a message will be rejected if the difference in timestamp exceeds this threshold. This configuration is ignored if log.message.timestamp.type=LogAppendTime.The maximum timestamp difference allowed should be no greater than log.retention.ms to avoid unnecessarily [...]
+<tr>
+<td>log.message.timestamp.type</td></td><td>Define whether the timestamp in the message is message create time or log append time. The value should be either `CreateTime` or `LogAppendTime`</td></td><td>string</td></td><td>CreateTime</td></td><td>[CreateTime, LogAppendTime]</td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.preallocate</td></td><td>Should pre allocate file when create new segment? If you are using Kafka on Windows, you probably need to set it to true.</td></td><td>boolean</td></td><td>false</td></td><td></td></td><td>medium</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>log.retention.check.interval.ms</td></td><td>The frequency in milliseconds that the log cleaner checks whether any log is eligible for deletion</td></td><td>long</td></td><td>300000</td></td><td>[1,...]</td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>max.connections.per.ip</td></td><td>The maximum number of connections we allow from each ip address</td></td><td>int</td></td><td>2147483647</td></td><td>[1,...]</td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>max.connections.per.ip.overrides</td></td><td>Per-ip or hostname overrides to the default maximum number of connections</td></td><td>string</td></td><td>""</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>max.incremental.fetch.session.cache.slots</td></td><td>The maximum number of incremental fetch sessions that we will maintain.</td></td><td>int</td></td><td>1000</td></td><td>[0,...]</td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>num.partitions</td></td><td>The default number of log partitions per topic</td></td><td>int</td></td><td>1</td></td><td>[1,...]</td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>password.encoder.old.secret</td></td><td>The old secret that was used for encoding dynamically configured passwords. This is required only when the secret is updated. If specified, all dynamically encoded passwords are decoded using this old secret and re-encoded using password.encoder.secret when broker starts up.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>password.encoder.secret</td></td><td>The secret used for encoding dynamically configured passwords for this broker.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>principal.builder.class</td></td><td>The fully qualified name of a class that implements the KafkaPrincipalBuilder interface, which is used to build the KafkaPrincipal object used during authorization. This config also supports the deprecated PrincipalBuilder interface which was previously used for client authentication over SSL. If no principal builder is defined, the default behavior depends on the security protocol in use. For SSL authentication, the principal name will be the dis [...]
+<tr>
+<td>producer.purgatory.purge.interval.requests</td></td><td>The purge interval (in number of requests) of the producer request purgatory</td></td><td>int</td></td><td>1000</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>queued.max.request.bytes</td></td><td>The number of queued bytes allowed before no more requests are read</td></td><td>long</td></td><td>-1</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>replica.fetch.backoff.ms</td></td><td>The amount of time to sleep when fetch partition error occurs.</td></td><td>int</td></td><td>1000</td></td><td>[0,...]</td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>replica.fetch.max.bytes</td></td><td>The number of bytes of messages to attempt to fetch for each partition. This is not an absolute maximum, if the first record batch in the first non-empty partition of the fetch is larger than this value, the record batch will still be returned to ensure that progress can be made. The maximum record batch size accepted by the broker is defined via <code>message.max.bytes</code> (broker config) or <code>max.message.bytes</code> (topic config).</td>< [...]
+<tr>
+<td>replica.fetch.response.max.bytes</td></td><td>Maximum bytes expected for the entire fetch response. Records are fetched in batches, and if the first record batch in the first non-empty partition of the fetch is larger than this value, the record batch will still be returned to ensure that progress can be made. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined via <code>message.max.bytes</code> (broker config) or <code>max.messag [...]
+<tr>
+<td>reserved.broker.max.id</td></td><td>Max number that can be used for a broker.id</td></td><td>int</td></td><td>1000</td></td><td>[0,...]</td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>sasl.enabled.mechanisms</td></td><td>The list of SASL mechanisms enabled in the Kafka server. The list may contain any mechanism for which a security provider is available. Only GSSAPI is enabled by default.</td></td><td>list</td></td><td>GSSAPI</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>sasl.jaas.config</td></td><td>JAAS login context parameters for SASL connections in the format used by JAAS configuration files. JAAS configuration file format is described <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/LoginConfigFile.html">here</a>. The format for the value is: '<loginModuleClass> <controlFlag> (<optionName>=<optionValue>)*;'</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>sasl.kerberos.kinit.cmd</td></td><td>Kerberos kinit command path.</td></td><td>string</td></td><td>/usr/bin/kinit</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>sasl.kerberos.min.time.before.relogin</td></td><td>Login thread sleep time between refresh attempts.</td></td><td>long</td></td><td>60000</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>sasl.kerberos.principal.to.local.rules</td></td><td>A list of rules for mapping from principal names to short names (typically operating system usernames). The rules are evaluated in order and the first rule that matches a principal name is used to map it to a short name. Any later rules in the list are ignored. By default, principal names of the form {username}/{hostname}@{REALM} are mapped to {username}. For more details on the format please see <a href="#security_authz"> security [...]
+<tr>
+<td>sasl.kerberos.service.name</td></td><td>The Kerberos principal name that Kafka runs as. This can be defined either in Kafka's JAAS config or in Kafka's config.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.jitter</td></td><td>Percentage of random jitter added to the renewal time.</td></td><td>double</td></td><td>0.05</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.window.factor</td></td><td>Login thread will sleep until the specified window factor of time from last refresh to ticket's expiry has been reached, at which time it will try to renew the ticket.</td></td><td>double</td></td><td>0.8</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>sasl.mechanism.inter.broker.protocol</td></td><td>SASL mechanism used for inter-broker communication. Default is GSSAPI.</td></td><td>string</td></td><td>GSSAPI</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>security.inter.broker.protocol</td></td><td>Security protocol used to communicate between brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL. It is an error to set this and inter.broker.listener.name properties at the same time.</td></td><td>string</td></td><td>PLAINTEXT</td></td><td></td></td><td>medium</td></td><td>read-only</td></tr>
+<tr>
+<td>ssl.cipher.suites</td></td><td>A list of cipher suites. This is a named combination of authentication, encryption, MAC and key exchange algorithm used to negotiate the security settings for a network connection using TLS or SSL network protocol. By default all the available cipher suites are supported.</td></td><td>list</td></td><td>""</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.client.auth</td></td><td>Configures kafka broker to request client authentication. The following settings are common: <ul> <li><code>ssl.client.auth=required</code> If set to required client authentication is required. <li><code>ssl.client.auth=requested</code> This means client authentication is optional. unlike requested , if this option is set client can choose not to provide authentication information about itself <li><code>ssl.client.auth=none</code> This means client authe [...]
+<tr>
+<td>ssl.enabled.protocols</td></td><td>The list of protocols enabled for SSL connections.</td></td><td>list</td></td><td>TLSv1.2,TLSv1.1,TLSv1</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.key.password</td></td><td>The password of the private key in the key store file. This is optional for client.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.keymanager.algorithm</td></td><td>The algorithm used by key manager factory for SSL connections. Default value is the key manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>SunX509</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.keystore.location</td></td><td>The location of the key store file. This is optional for client and can be used for two-way authentication for client.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.keystore.password</td></td><td>The store password for the key store file. This is optional for client and only needed if ssl.keystore.location is configured. </td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.keystore.type</td></td><td>The file format of the key store file. This is optional for client.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.protocol</td></td><td>The SSL protocol used to generate the SSLContext. Default setting is TLS, which is fine for most cases. Allowed values in recent JVMs are TLS, TLSv1.1 and TLSv1.2. SSL, SSLv2 and SSLv3 may be supported in older JVMs, but their usage is discouraged due to known security vulnerabilities.</td></td><td>string</td></td><td>TLS</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.provider</td></td><td>The name of the security provider used for SSL connections. Default value is the default security provider of the JVM.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.trustmanager.algorithm</td></td><td>The algorithm used by trust manager factory for SSL connections. Default value is the trust manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>PKIX</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.truststore.location</td></td><td>The location of the trust store file. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.truststore.password</td></td><td>The password for the trust store file. If a password is not set access to the truststore is still available, but integrity checking is disabled.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.truststore.type</td></td><td>The file format of the trust store file.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td><td>per-broker</td></tr>
+<tr>
+<td>alter.config.policy.class.name</td></td><td>The alter configs policy class that should be used for validation. The class should implement the <code>org.apache.kafka.server.policy.AlterConfigPolicy</code> interface.</td></td><td>class</td></td><td>null</td></td><td></td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>alter.log.dirs.replication.quota.window.num</td></td><td>The number of samples to retain in memory for alter log dirs replication quotas</td></td><td>int</td></td><td>11</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>alter.log.dirs.replication.quota.window.size.seconds</td></td><td>The time span of each sample for alter log dirs replication quotas</td></td><td>int</td></td><td>1</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>authorizer.class.name</td></td><td>The authorizer class that should be used for authorization</td></td><td>string</td></td><td>""</td></td><td></td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>create.topic.policy.class.name</td></td><td>The create topic policy class that should be used for validation. The class should implement the <code>org.apache.kafka.server.policy.CreateTopicPolicy</code> interface.</td></td><td>class</td></td><td>null</td></td><td></td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>delegation.token.expiry.check.interval.ms</td></td><td>Scan interval to remove expired delegation tokens.</td></td><td>long</td></td><td>3600000</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>listener.security.protocol.map</td></td><td>Map between listener names and security protocols. This must be defined for the same security protocol to be usable in more than one port or IP. For example, internal and external traffic can be separated even if SSL is required for both. Concretely, the user could define listeners with names INTERNAL and EXTERNAL and this property as: `INTERNAL:SSL,EXTERNAL:SSL`. As shown, key and value are separated by a colon and map entries are separate [...]
+<tr>
+<td>metric.reporters</td></td><td>A list of classes to use as metrics reporters. Implementing the <code>org.apache.kafka.common.metrics.MetricsReporter</code> interface allows plugging in classes that will be notified of new metric creation. The JmxReporter is always included to register JMX statistics.</td></td><td>list</td></td><td>""</td></td><td></td></td><td>low</td></td><td>cluster-wide</td></tr>
+<tr>
+<td>metrics.num.samples</td></td><td>The number of samples maintained to compute metrics.</td></td><td>int</td></td><td>2</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>metrics.recording.level</td></td><td>The highest recording level for metrics.</td></td><td>string</td></td><td>INFO</td></td><td></td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>metrics.sample.window.ms</td></td><td>The window of time a metrics sample is computed over.</td></td><td>long</td></td><td>30000</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>password.encoder.cipher.algorithm</td></td><td>The Cipher algorithm used for encoding dynamically configured passwords.</td></td><td>string</td></td><td>AES/CBC/PKCS5Padding</td></td><td></td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>password.encoder.iterations</td></td><td>The iteration count used for encoding dynamically configured passwords.</td></td><td>int</td></td><td>4096</td></td><td>[1024,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>password.encoder.key.length</td></td><td>The key length used for encoding dynamically configured passwords.</td></td><td>int</td></td><td>128</td></td><td>[8,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>password.encoder.keyfactory.algorithm</td></td><td>The SecretKeyFactory algorithm used for encoding dynamically configured passwords. Default is PBKDF2WithHmacSHA512 if available and PBKDF2WithHmacSHA1 otherwise.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>quota.window.num</td></td><td>The number of samples to retain in memory for client quotas</td></td><td>int</td></td><td>11</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>quota.window.size.seconds</td></td><td>The time span of each sample for client quotas</td></td><td>int</td></td><td>1</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>replication.quota.window.num</td></td><td>The number of samples to retain in memory for replication quotas</td></td><td>int</td></td><td>11</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>replication.quota.window.size.seconds</td></td><td>The time span of each sample for replication quotas</td></td><td>int</td></td><td>1</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>ssl.endpoint.identification.algorithm</td></td><td>The endpoint identification algorithm to validate server hostname using server certificate. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td><td>per-broker</td></tr>
+<tr>
+<td>ssl.secure.random.implementation</td></td><td>The SecureRandom PRNG implementation to use for SSL cryptography operations. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td><td>per-broker</td></tr>
+<tr>
+<td>transaction.abort.timed.out.transaction.cleanup.interval.ms</td></td><td>The interval at which to rollback transactions that have timed out</td></td><td>int</td></td><td>60000</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>transaction.remove.expired.transaction.cleanup.interval.ms</td></td><td>The interval at which to remove transactions that have expired due to <code>transactional.id.expiration.ms<code> passing</td></td><td>int</td></td><td>3600000</td></td><td>[1,...]</td></td><td>low</td></td><td>read-only</td></tr>
+<tr>
+<td>zookeeper.sync.time.ms</td></td><td>How far a ZK follower can be behind a ZK leader</td></td><td>int</td></td><td>2000</td></td><td></td></td><td>low</td></td><td>read-only</td></tr>
+</tbody></table>
diff --git a/11/generated/producer_config.html b/11/generated/producer_config.html
new file mode 100644
index 0000000..f0a92b6
--- /dev/null
+++ b/11/generated/producer_config.html
@@ -0,0 +1,116 @@
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>key.serializer</td></td><td>Serializer class for key that implements the <code>org.apache.kafka.common.serialization.Serializer</code> interface.</td></td><td>class</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>value.serializer</td></td><td>Serializer class for value that implements the <code>org.apache.kafka.common.serialization.Serializer</code> interface.</td></td><td>class</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>acks</td></td><td>The number of acknowledgments the producer requires the leader to have received before considering a request complete. This controls the durability of records that are sent. The following settings are allowed: <ul> <li><code>acks=0</code> If set to zero then the producer will not wait for any acknowledgment from the server at all. The record will be immediately added to the socket buffer and considered sent. No guarantee can be made that the server has received th [...]
+<tr>
+<td>bootstrap.servers</td></td><td>A list of host/port pairs to use for establishing the initial connection to the Kafka cluster. The client will make use of all servers irrespective of which servers are specified here for bootstrapping—this list only impacts the initial hosts used to discover the full set of servers. This list should be in the form <code>host1:port1,host2:port2,...</code>. Since these servers are just used for the initial connection to discover the full cluster me [...]
+<tr>
+<td>buffer.memory</td></td><td>The total bytes of memory the producer can use to buffer records waiting to be sent to the server. If records are sent faster than they can be delivered to the server the producer will block for <code>max.block.ms</code> after which it will throw an exception.<p>This setting should correspond roughly to the total memory the producer will use, but is not a hard bound since not all memory the producer uses is used for buffering. Some additional memory will be [...]
+<tr>
+<td>compression.type</td></td><td>The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are <code>none</code>, <code>gzip</code>, <code>snappy</code>, or <code>lz4</code>. Compression is of full batches of data, so the efficacy of batching will also impact the compression ratio (more batching means better compression).</td></td><td>string</td></td><td>none</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>retries</td></td><td>Setting a value greater than zero will cause the client to resend any record whose send fails with a potentially transient error. Note that this retry is no different than if the client resent the record upon receiving the error. Allowing retries without setting <code>max.in.flight.requests.per.connection</code> to 1 will potentially change the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the se [...]
+<tr>
+<td>ssl.key.password</td></td><td>The password of the private key in the key store file. This is optional for client.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.keystore.location</td></td><td>The location of the key store file. This is optional for client and can be used for two-way authentication for client.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.keystore.password</td></td><td>The store password for the key store file. This is optional for client and only needed if ssl.keystore.location is configured. </td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.truststore.location</td></td><td>The location of the trust store file. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>ssl.truststore.password</td></td><td>The password for the trust store file. If a password is not set access to the truststore is still available, but integrity checking is disabled.</td></td><td>password</td></td><td>null</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>batch.size</td></td><td>The producer will attempt to batch records together into fewer requests whenever multiple records are being sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. <p>No attempt will be made to batch records larger than this size. <p>Requests sent to brokers will contain multiple batches, one for each partition with data available to be sent. <p>A small batch size will m [...]
+<tr>
+<td>client.id</td></td><td>An id string to pass to the server when making requests. The purpose of this is to be able to track the source of requests beyond just ip/port by allowing a logical application name to be included in server-side request logging.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>connections.max.idle.ms</td></td><td>Close idle connections after the number of milliseconds specified by this config.</td></td><td>long</td></td><td>540000</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>linger.ms</td></td><td>The producer groups together any records that arrive in between request transmissions into a single batched request. Normally this occurs only under load when records arrive faster than they can be sent out. However in some circumstances the client may want to reduce the number of requests even under moderate load. This setting accomplishes this by adding a small amount of artificial delay—that is, rather than immediately sending out a record the producer [...]
+<tr>
+<td>max.block.ms</td></td><td>The configuration controls how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> will block.These methods can be blocked either because the buffer is full or metadata unavailable.Blocking in the user-supplied serializers or partitioner will not be counted against this timeout.</td></td><td>long</td></td><td>60000</td></td><td>[0,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>max.request.size</td></td><td>The maximum size of a request in bytes. This setting will limit the number of record batches the producer will send in a single request to avoid sending huge requests. This is also effectively a cap on the maximum record batch size. Note that the server has its own cap on record batch size which may be different from this.</td></td><td>int</td></td><td>1048576</td></td><td>[0,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>partitioner.class</td></td><td>Partitioner class that implements the <code>org.apache.kafka.clients.producer.Partitioner</code> interface.</td></td><td>class</td></td><td>org.apache.kafka.clients.producer.internals.DefaultPartitioner</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>receive.buffer.bytes</td></td><td>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>32768</td></td><td>[-1,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>request.timeout.ms</td></td><td>The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted. This should be larger than replica.lag.time.max.ms (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</td></td><td>int</td></td><td>30000 [...]
+<tr>
+<td>sasl.jaas.config</td></td><td>JAAS login context parameters for SASL connections in the format used by JAAS configuration files. JAAS configuration file format is described <a href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/tutorials/LoginConfigFile.html">here</a>. The format for the value is: '<loginModuleClass> <controlFlag> (<optionName>=<optionValue>)*;'</td></td><td>password</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.kerberos.service.name</td></td><td>The Kerberos principal name that Kafka runs as. This can be defined either in Kafka's JAAS config or in Kafka's config.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>sasl.mechanism</td></td><td>SASL mechanism used for client connections. This may be any mechanism for which a security provider is available. GSSAPI is the default mechanism.</td></td><td>string</td></td><td>GSSAPI</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>security.protocol</td></td><td>Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.</td></td><td>string</td></td><td>PLAINTEXT</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>send.buffer.bytes</td></td><td>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>131072</td></td><td>[-1,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.enabled.protocols</td></td><td>The list of protocols enabled for SSL connections.</td></td><td>list</td></td><td>TLSv1.2,TLSv1.1,TLSv1</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.keystore.type</td></td><td>The file format of the key store file. This is optional for client.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.protocol</td></td><td>The SSL protocol used to generate the SSLContext. Default setting is TLS, which is fine for most cases. Allowed values in recent JVMs are TLS, TLSv1.1 and TLSv1.2. SSL, SSLv2 and SSLv3 may be supported in older JVMs, but their usage is discouraged due to known security vulnerabilities.</td></td><td>string</td></td><td>TLS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.provider</td></td><td>The name of the security provider used for SSL connections. Default value is the default security provider of the JVM.</td></td><td>string</td></td><td>null</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>ssl.truststore.type</td></td><td>The file format of the trust store file.</td></td><td>string</td></td><td>JKS</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>enable.idempotence</td></td><td>When set to 'true', the producer will ensure that exactly one copy of each message is written in the stream. If 'false', producer retries due to broker failures, etc., may write duplicates of the retried message in the stream. Note that enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to 5, <code>retries</code> to be greater than 0 and acks must be 'all'. If these values are not explicitly set by [...]
+<tr>
+<td>interceptor.classes</td></td><td>A list of classes to use as interceptors. Implementing the <code>org.apache.kafka.clients.producer.ProducerInterceptor</code> interface allows you to intercept (and possibly mutate) the records received by the producer before they are published to the Kafka cluster. By default, there are no interceptors.</td></td><td>list</td></td><td>""</td></td><td>org.apache.kafka.common.config.ConfigDef$NonNullValidator@6944ffa4</td></td><td>low</td></td></tr>
+<tr>
+<td>max.in.flight.requests.per.connection</td></td><td>The maximum number of unacknowledged requests the client will send on a single connection before blocking. Note that if this setting is set to be greater than 1 and there are failed sends, there is a risk of message re-ordering due to retries (i.e., if retries are enabled).</td></td><td>int</td></td><td>5</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metadata.max.age.ms</td></td><td>The period of time in milliseconds after which we force a refresh of metadata even if we haven't seen any partition leadership changes to proactively discover any new brokers or partitions.</td></td><td>long</td></td><td>300000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metric.reporters</td></td><td>A list of classes to use as metrics reporters. Implementing the <code>org.apache.kafka.common.metrics.MetricsReporter</code> interface allows plugging in classes that will be notified of new metric creation. The JmxReporter is always included to register JMX statistics.</td></td><td>list</td></td><td>""</td></td><td>org.apache.kafka.common.config.ConfigDef$NonNullValidator@30eb9dfa</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.num.samples</td></td><td>The number of samples maintained to compute metrics.</td></td><td>int</td></td><td>2</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.recording.level</td></td><td>The highest recording level for metrics.</td></td><td>string</td></td><td>INFO</td></td><td>[INFO, DEBUG]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.sample.window.ms</td></td><td>The window of time a metrics sample is computed over.</td></td><td>long</td></td><td>30000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.max.ms</td></td><td>The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.</td></td><td>long</td></td><td>1000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.ms</td></td><td>The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker.</td></td><td>long</td></td><td>50</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>retry.backoff.ms</td></td><td>The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios.</td></td><td>long</td></td><td>100</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.kinit.cmd</td></td><td>Kerberos kinit command path.</td></td><td>string</td></td><td>/usr/bin/kinit</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.min.time.before.relogin</td></td><td>Login thread sleep time between refresh attempts.</td></td><td>long</td></td><td>60000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.jitter</td></td><td>Percentage of random jitter added to the renewal time.</td></td><td>double</td></td><td>0.05</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>sasl.kerberos.ticket.renew.window.factor</td></td><td>Login thread will sleep until the specified window factor of time from last refresh to ticket's expiry has been reached, at which time it will try to renew the ticket.</td></td><td>double</td></td><td>0.8</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.cipher.suites</td></td><td>A list of cipher suites. This is a named combination of authentication, encryption, MAC and key exchange algorithm used to negotiate the security settings for a network connection using TLS or SSL network protocol. By default all the available cipher suites are supported.</td></td><td>list</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.endpoint.identification.algorithm</td></td><td>The endpoint identification algorithm to validate server hostname using server certificate. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.keymanager.algorithm</td></td><td>The algorithm used by key manager factory for SSL connections. Default value is the key manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>SunX509</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.secure.random.implementation</td></td><td>The SecureRandom PRNG implementation to use for SSL cryptography operations. </td></td><td>string</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>ssl.trustmanager.algorithm</td></td><td>The algorithm used by trust manager factory for SSL connections. Default value is the trust manager factory algorithm configured for the Java Virtual Machine.</td></td><td>string</td></td><td>PKIX</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>transaction.timeout.ms</td></td><td>The maximum amount of time in ms that the transaction coordinator will wait for a transaction status update from the producer before proactively aborting the ongoing transaction.If this value is larger than the max.transaction.timeout.ms setting in the broker, the request will fail with a `InvalidTransactionTimeout` error.</td></td><td>int</td></td><td>60000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>transactional.id</td></td><td>The TransactionalId to use for transactional delivery. This enables reliability semantics which span multiple producer sessions since it allows the client to guarantee that transactions using the same TransactionalId have been completed prior to starting any new transactions. If no TransactionalId is provided, then the producer is limited to idempotent delivery. Note that enable.idempotence must be enabled if a TransactionalId is configured. The default [...]
+</tbody></table>
diff --git a/11/generated/producer_metrics.html b/11/generated/producer_metrics.html
new file mode 100644
index 0000000..deb4078
--- /dev/null
+++ b/11/generated/producer_metrics.html
@@ -0,0 +1,78 @@
+<table class="data-table"><tbody>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.producer:type=producer-metrics,client-id="{client-id}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>batch-size-avg</td><td>The average number of bytes sent per partition per-request.</td></tr>
+<tr>
+<td></td><td>batch-size-max</td><td>The max number of bytes sent per partition per-request.</td></tr>
+<tr>
+<td></td><td>batch-split-rate</td><td>The average number of batch splits per second</td></tr>
+<tr>
+<td></td><td>batch-split-total</td><td>The total number of batch splits</td></tr>
+<tr>
+<td></td><td>compression-rate-avg</td><td>The average compression rate of record batches.</td></tr>
+<tr>
+<td></td><td>metadata-age</td><td>The age in seconds of the current producer metadata being used.</td></tr>
+<tr>
+<td></td><td>produce-throttle-time-avg</td><td>The average time in ms a request was throttled by a broker</td></tr>
+<tr>
+<td></td><td>produce-throttle-time-max</td><td>The maximum time in ms a request was throttled by a broker</td></tr>
+<tr>
+<td></td><td>record-error-rate</td><td>The average per-second number of record sends that resulted in errors</td></tr>
+<tr>
+<td></td><td>record-error-total</td><td>The total number of record sends that resulted in errors</td></tr>
+<tr>
+<td></td><td>record-queue-time-avg</td><td>The average time in ms record batches spent in the send buffer.</td></tr>
+<tr>
+<td></td><td>record-queue-time-max</td><td>The maximum time in ms record batches spent in the send buffer.</td></tr>
+<tr>
+<td></td><td>record-retry-rate</td><td>The average per-second number of retried record sends</td></tr>
+<tr>
+<td></td><td>record-retry-total</td><td>The total number of retried record sends</td></tr>
+<tr>
+<td></td><td>record-send-rate</td><td>The average number of records sent per second.</td></tr>
+<tr>
+<td></td><td>record-send-total</td><td>The total number of records sent.</td></tr>
+<tr>
+<td></td><td>record-size-avg</td><td>The average record size</td></tr>
+<tr>
+<td></td><td>record-size-max</td><td>The maximum record size</td></tr>
+<tr>
+<td></td><td>records-per-request-avg</td><td>The average number of records per request.</td></tr>
+<tr>
+<td></td><td>request-latency-avg</td><td>The average request latency in ms</td></tr>
+<tr>
+<td></td><td>request-latency-max</td><td>The maximum request latency in ms</td></tr>
+<tr>
+<td></td><td>requests-in-flight</td><td>The current number of in-flight requests awaiting a response.</td></tr>
+<tr>
+<td colspan=3 class="mbeanName" style="background-color:#ccc; font-weight: bold;">kafka.producer:type=producer-topic-metrics,client-id="{client-id}",topic="{topic}"</td></tr>
+<tr>
+<th style="width: 90px"></th>
+<th>Attribute name</th>
+<th>Description</th>
+</tr>
+<tr>
+<td></td><td>byte-rate</td><td>The average number of bytes sent per second for a topic.</td></tr>
+<tr>
+<td></td><td>byte-total</td><td>The total number of bytes sent for a topic.</td></tr>
+<tr>
+<td></td><td>compression-rate</td><td>The average compression rate of record batches for a topic.</td></tr>
+<tr>
+<td></td><td>record-error-rate</td><td>The average per-second number of record sends that resulted in errors for a topic</td></tr>
+<tr>
+<td></td><td>record-error-total</td><td>The total number of record sends that resulted in errors for a topic</td></tr>
+<tr>
+<td></td><td>record-retry-rate</td><td>The average per-second number of retried record sends for a topic</td></tr>
+<tr>
+<td></td><td>record-retry-total</td><td>The total number of retried record sends for a topic</td></tr>
+<tr>
+<td></td><td>record-send-rate</td><td>The average number of records sent per second for a topic.</td></tr>
+<tr>
+<td></td><td>record-send-total</td><td>The total number of records sent for a topic.</td></tr>
+</tbody></table>
diff --git a/11/generated/protocol_api_keys.html b/11/generated/protocol_api_keys.html
new file mode 100644
index 0000000..923716a
--- /dev/null
+++ b/11/generated/protocol_api_keys.html
@@ -0,0 +1,91 @@
+<table class="data-table"><tbody>
+<tr><th>Name</th>
+<th>Key</th>
+</tr><tr>
+<td><a href="#The_Messages_Produce">Produce</a></td><td>0</td></tr>
+<tr>
+<td><a href="#The_Messages_Fetch">Fetch</a></td><td>1</td></tr>
+<tr>
+<td><a href="#The_Messages_ListOffsets">ListOffsets</a></td><td>2</td></tr>
+<tr>
+<td><a href="#The_Messages_Metadata">Metadata</a></td><td>3</td></tr>
+<tr>
+<td><a href="#The_Messages_LeaderAndIsr">LeaderAndIsr</a></td><td>4</td></tr>
+<tr>
+<td><a href="#The_Messages_StopReplica">StopReplica</a></td><td>5</td></tr>
+<tr>
+<td><a href="#The_Messages_UpdateMetadata">UpdateMetadata</a></td><td>6</td></tr>
+<tr>
+<td><a href="#The_Messages_ControlledShutdown">ControlledShutdown</a></td><td>7</td></tr>
+<tr>
+<td><a href="#The_Messages_OffsetCommit">OffsetCommit</a></td><td>8</td></tr>
+<tr>
+<td><a href="#The_Messages_OffsetFetch">OffsetFetch</a></td><td>9</td></tr>
+<tr>
+<td><a href="#The_Messages_FindCoordinator">FindCoordinator</a></td><td>10</td></tr>
+<tr>
+<td><a href="#The_Messages_JoinGroup">JoinGroup</a></td><td>11</td></tr>
+<tr>
+<td><a href="#The_Messages_Heartbeat">Heartbeat</a></td><td>12</td></tr>
+<tr>
+<td><a href="#The_Messages_LeaveGroup">LeaveGroup</a></td><td>13</td></tr>
+<tr>
+<td><a href="#The_Messages_SyncGroup">SyncGroup</a></td><td>14</td></tr>
+<tr>
+<td><a href="#The_Messages_DescribeGroups">DescribeGroups</a></td><td>15</td></tr>
+<tr>
+<td><a href="#The_Messages_ListGroups">ListGroups</a></td><td>16</td></tr>
+<tr>
+<td><a href="#The_Messages_SaslHandshake">SaslHandshake</a></td><td>17</td></tr>
+<tr>
+<td><a href="#The_Messages_ApiVersions">ApiVersions</a></td><td>18</td></tr>
+<tr>
+<td><a href="#The_Messages_CreateTopics">CreateTopics</a></td><td>19</td></tr>
+<tr>
+<td><a href="#The_Messages_DeleteTopics">DeleteTopics</a></td><td>20</td></tr>
+<tr>
+<td><a href="#The_Messages_DeleteRecords">DeleteRecords</a></td><td>21</td></tr>
+<tr>
+<td><a href="#The_Messages_InitProducerId">InitProducerId</a></td><td>22</td></tr>
+<tr>
+<td><a href="#The_Messages_OffsetForLeaderEpoch">OffsetForLeaderEpoch</a></td><td>23</td></tr>
+<tr>
+<td><a href="#The_Messages_AddPartitionsToTxn">AddPartitionsToTxn</a></td><td>24</td></tr>
+<tr>
+<td><a href="#The_Messages_AddOffsetsToTxn">AddOffsetsToTxn</a></td><td>25</td></tr>
+<tr>
+<td><a href="#The_Messages_EndTxn">EndTxn</a></td><td>26</td></tr>
+<tr>
+<td><a href="#The_Messages_WriteTxnMarkers">WriteTxnMarkers</a></td><td>27</td></tr>
+<tr>
+<td><a href="#The_Messages_TxnOffsetCommit">TxnOffsetCommit</a></td><td>28</td></tr>
+<tr>
+<td><a href="#The_Messages_DescribeAcls">DescribeAcls</a></td><td>29</td></tr>
+<tr>
+<td><a href="#The_Messages_CreateAcls">CreateAcls</a></td><td>30</td></tr>
+<tr>
+<td><a href="#The_Messages_DeleteAcls">DeleteAcls</a></td><td>31</td></tr>
+<tr>
+<td><a href="#The_Messages_DescribeConfigs">DescribeConfigs</a></td><td>32</td></tr>
+<tr>
+<td><a href="#The_Messages_AlterConfigs">AlterConfigs</a></td><td>33</td></tr>
+<tr>
+<td><a href="#The_Messages_AlterReplicaLogDirs">AlterReplicaLogDirs</a></td><td>34</td></tr>
+<tr>
+<td><a href="#The_Messages_DescribeLogDirs">DescribeLogDirs</a></td><td>35</td></tr>
+<tr>
+<td><a href="#The_Messages_SaslAuthenticate">SaslAuthenticate</a></td><td>36</td></tr>
+<tr>
+<td><a href="#The_Messages_CreatePartitions">CreatePartitions</a></td><td>37</td></tr>
+<tr>
+<td><a href="#The_Messages_CreateDelegationToken">CreateDelegationToken</a></td><td>38</td></tr>
+<tr>
+<td><a href="#The_Messages_RenewDelegationToken">RenewDelegationToken</a></td><td>39</td></tr>
+<tr>
+<td><a href="#The_Messages_ExpireDelegationToken">ExpireDelegationToken</a></td><td>40</td></tr>
+<tr>
+<td><a href="#The_Messages_DescribeDelegationToken">DescribeDelegationToken</a></td><td>41</td></tr>
+<tr>
+<td><a href="#The_Messages_DeleteGroups">DeleteGroups</a></td><td>42</td></tr>
+</table>
+
diff --git a/11/generated/protocol_errors.html b/11/generated/protocol_errors.html
new file mode 100644
index 0000000..5532c0f
--- /dev/null
+++ b/11/generated/protocol_errors.html
@@ -0,0 +1,81 @@
+<table class="data-table"><tbody>
+<tr><th>Error</th>
+<th>Code</th>
+<th>Retriable</th>
+<th>Description</th>
+</tr>
+<tr><td>UNKNOWN_SERVER_ERROR</td><td>-1</td><td>False</td><td>The server experienced an unexpected error when processing the request</td></tr>
+<tr><td>NONE</td><td>0</td><td>False</td><td></td></tr>
+<tr><td>OFFSET_OUT_OF_RANGE</td><td>1</td><td>False</td><td>The requested offset is not within the range of offsets maintained by the server.</td></tr>
+<tr><td>CORRUPT_MESSAGE</td><td>2</td><td>True</td><td>This message has failed its CRC checksum, exceeds the valid size, or is otherwise corrupt.</td></tr>
+<tr><td>UNKNOWN_TOPIC_OR_PARTITION</td><td>3</td><td>True</td><td>This server does not host this topic-partition.</td></tr>
+<tr><td>INVALID_FETCH_SIZE</td><td>4</td><td>False</td><td>The requested fetch size is invalid.</td></tr>
+<tr><td>LEADER_NOT_AVAILABLE</td><td>5</td><td>True</td><td>There is no leader for this topic-partition as we are in the middle of a leadership election.</td></tr>
+<tr><td>NOT_LEADER_FOR_PARTITION</td><td>6</td><td>True</td><td>This server is not the leader for that topic-partition.</td></tr>
+<tr><td>REQUEST_TIMED_OUT</td><td>7</td><td>True</td><td>The request timed out.</td></tr>
+<tr><td>BROKER_NOT_AVAILABLE</td><td>8</td><td>False</td><td>The broker is not available.</td></tr>
+<tr><td>REPLICA_NOT_AVAILABLE</td><td>9</td><td>False</td><td>The replica is not available for the requested topic-partition</td></tr>
+<tr><td>MESSAGE_TOO_LARGE</td><td>10</td><td>False</td><td>The request included a message larger than the max message size the server will accept.</td></tr>
+<tr><td>STALE_CONTROLLER_EPOCH</td><td>11</td><td>False</td><td>The controller moved to another broker.</td></tr>
+<tr><td>OFFSET_METADATA_TOO_LARGE</td><td>12</td><td>False</td><td>The metadata field of the offset request was too large.</td></tr>
+<tr><td>NETWORK_EXCEPTION</td><td>13</td><td>True</td><td>The server disconnected before a response was received.</td></tr>
+<tr><td>COORDINATOR_LOAD_IN_PROGRESS</td><td>14</td><td>True</td><td>The coordinator is loading and hence can't process requests.</td></tr>
+<tr><td>COORDINATOR_NOT_AVAILABLE</td><td>15</td><td>True</td><td>The coordinator is not available.</td></tr>
+<tr><td>NOT_COORDINATOR</td><td>16</td><td>True</td><td>This is not the correct coordinator.</td></tr>
+<tr><td>INVALID_TOPIC_EXCEPTION</td><td>17</td><td>False</td><td>The request attempted to perform an operation on an invalid topic.</td></tr>
+<tr><td>RECORD_LIST_TOO_LARGE</td><td>18</td><td>False</td><td>The request included message batch larger than the configured segment size on the server.</td></tr>
+<tr><td>NOT_ENOUGH_REPLICAS</td><td>19</td><td>True</td><td>Messages are rejected since there are fewer in-sync replicas than required.</td></tr>
+<tr><td>NOT_ENOUGH_REPLICAS_AFTER_APPEND</td><td>20</td><td>True</td><td>Messages are written to the log, but to fewer in-sync replicas than required.</td></tr>
+<tr><td>INVALID_REQUIRED_ACKS</td><td>21</td><td>False</td><td>Produce request specified an invalid value for required acks.</td></tr>
+<tr><td>ILLEGAL_GENERATION</td><td>22</td><td>False</td><td>Specified group generation id is not valid.</td></tr>
+<tr><td>INCONSISTENT_GROUP_PROTOCOL</td><td>23</td><td>False</td><td>The group member's supported protocols are incompatible with those of existing members or first group member tried to join with empty protocol type or empty protocol list.</td></tr>
+<tr><td>INVALID_GROUP_ID</td><td>24</td><td>False</td><td>The configured groupId is invalid</td></tr>
+<tr><td>UNKNOWN_MEMBER_ID</td><td>25</td><td>False</td><td>The coordinator is not aware of this member.</td></tr>
+<tr><td>INVALID_SESSION_TIMEOUT</td><td>26</td><td>False</td><td>The session timeout is not within the range allowed by the broker (as configured by group.min.session.timeout.ms and group.max.session.timeout.ms).</td></tr>
+<tr><td>REBALANCE_IN_PROGRESS</td><td>27</td><td>False</td><td>The group is rebalancing, so a rejoin is needed.</td></tr>
+<tr><td>INVALID_COMMIT_OFFSET_SIZE</td><td>28</td><td>False</td><td>The committing offset data size is not valid</td></tr>
+<tr><td>TOPIC_AUTHORIZATION_FAILED</td><td>29</td><td>False</td><td>Not authorized to access topics: [Topic authorization failed.]</td></tr>
+<tr><td>GROUP_AUTHORIZATION_FAILED</td><td>30</td><td>False</td><td>Not authorized to access group: Group authorization failed.</td></tr>
+<tr><td>CLUSTER_AUTHORIZATION_FAILED</td><td>31</td><td>False</td><td>Cluster authorization failed.</td></tr>
+<tr><td>INVALID_TIMESTAMP</td><td>32</td><td>False</td><td>The timestamp of the message is out of acceptable range.</td></tr>
+<tr><td>UNSUPPORTED_SASL_MECHANISM</td><td>33</td><td>False</td><td>The broker does not support the requested SASL mechanism.</td></tr>
+<tr><td>ILLEGAL_SASL_STATE</td><td>34</td><td>False</td><td>Request is not valid given the current SASL state.</td></tr>
+<tr><td>UNSUPPORTED_VERSION</td><td>35</td><td>False</td><td>The version of API is not supported.</td></tr>
+<tr><td>TOPIC_ALREADY_EXISTS</td><td>36</td><td>False</td><td>Topic with this name already exists.</td></tr>
+<tr><td>INVALID_PARTITIONS</td><td>37</td><td>False</td><td>Number of partitions is invalid.</td></tr>
+<tr><td>INVALID_REPLICATION_FACTOR</td><td>38</td><td>False</td><td>Replication-factor is invalid.</td></tr>
+<tr><td>INVALID_REPLICA_ASSIGNMENT</td><td>39</td><td>False</td><td>Replica assignment is invalid.</td></tr>
+<tr><td>INVALID_CONFIG</td><td>40</td><td>False</td><td>Configuration is invalid.</td></tr>
+<tr><td>NOT_CONTROLLER</td><td>41</td><td>True</td><td>This is not the correct controller for this cluster.</td></tr>
+<tr><td>INVALID_REQUEST</td><td>42</td><td>False</td><td>This most likely occurs because of a request being malformed by the client library or the message was sent to an incompatible broker. See the broker logs for more details.</td></tr>
+<tr><td>UNSUPPORTED_FOR_MESSAGE_FORMAT</td><td>43</td><td>False</td><td>The message format version on the broker does not support the request.</td></tr>
+<tr><td>POLICY_VIOLATION</td><td>44</td><td>False</td><td>Request parameters do not satisfy the configured policy.</td></tr>
+<tr><td>OUT_OF_ORDER_SEQUENCE_NUMBER</td><td>45</td><td>False</td><td>The broker received an out of order sequence number</td></tr>
+<tr><td>DUPLICATE_SEQUENCE_NUMBER</td><td>46</td><td>False</td><td>The broker received a duplicate sequence number</td></tr>
+<tr><td>INVALID_PRODUCER_EPOCH</td><td>47</td><td>False</td><td>Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.</td></tr>
+<tr><td>INVALID_TXN_STATE</td><td>48</td><td>False</td><td>The producer attempted a transactional operation in an invalid state</td></tr>
+<tr><td>INVALID_PRODUCER_ID_MAPPING</td><td>49</td><td>False</td><td>The producer attempted to use a producer id which is not currently assigned to its transactional id</td></tr>
+<tr><td>INVALID_TRANSACTION_TIMEOUT</td><td>50</td><td>False</td><td>The transaction timeout is larger than the maximum value allowed by the broker (as configured by max.transaction.timeout.ms).</td></tr>
+<tr><td>CONCURRENT_TRANSACTIONS</td><td>51</td><td>False</td><td>The producer attempted to update a transaction while another concurrent operation on the same transaction was ongoing</td></tr>
+<tr><td>TRANSACTION_COORDINATOR_FENCED</td><td>52</td><td>False</td><td>Indicates that the transaction coordinator sending a WriteTxnMarker is no longer the current coordinator for a given producer</td></tr>
+<tr><td>TRANSACTIONAL_ID_AUTHORIZATION_FAILED</td><td>53</td><td>False</td><td>Transactional Id authorization failed</td></tr>
+<tr><td>SECURITY_DISABLED</td><td>54</td><td>False</td><td>Security features are disabled.</td></tr>
+<tr><td>OPERATION_NOT_ATTEMPTED</td><td>55</td><td>False</td><td>The broker did not attempt to execute this operation. This may happen for batched RPCs where some operations in the batch failed, causing the broker to respond without trying the rest.</td></tr>
+<tr><td>KAFKA_STORAGE_ERROR</td><td>56</td><td>True</td><td>Disk error when trying to access log file on the disk.</td></tr>
+<tr><td>LOG_DIR_NOT_FOUND</td><td>57</td><td>False</td><td>The user-specified log directory is not found in the broker config.</td></tr>
+<tr><td>SASL_AUTHENTICATION_FAILED</td><td>58</td><td>False</td><td>SASL Authentication failed.</td></tr>
+<tr><td>UNKNOWN_PRODUCER_ID</td><td>59</td><td>False</td><td>This exception is raised by the broker if it could not locate the producer metadata associated with the producerId in question. This could happen if, for instance, the producer's records were deleted because their retention time had elapsed. Once the last records of the producerId are removed, the producer's metadata is removed from the broker, and future appends by the producer will return this exception.</td></tr>
+<tr><td>REASSIGNMENT_IN_PROGRESS</td><td>60</td><td>False</td><td>A partition reassignment is in progress</td></tr>
+<tr><td>DELEGATION_TOKEN_AUTH_DISABLED</td><td>61</td><td>False</td><td>Delegation Token feature is not enabled.</td></tr>
+<tr><td>DELEGATION_TOKEN_NOT_FOUND</td><td>62</td><td>False</td><td>Delegation Token is not found on server.</td></tr>
+<tr><td>DELEGATION_TOKEN_OWNER_MISMATCH</td><td>63</td><td>False</td><td>Specified Principal is not valid Owner/Renewer.</td></tr>
+<tr><td>DELEGATION_TOKEN_REQUEST_NOT_ALLOWED</td><td>64</td><td>False</td><td>Delegation Token requests are not allowed on PLAINTEXT/1-way SSL channels and on delegation token authenticated channels.</td></tr>
+<tr><td>DELEGATION_TOKEN_AUTHORIZATION_FAILED</td><td>65</td><td>False</td><td>Delegation Token authorization failed.</td></tr>
+<tr><td>DELEGATION_TOKEN_EXPIRED</td><td>66</td><td>False</td><td>Delegation Token is expired.</td></tr>
+<tr><td>INVALID_PRINCIPAL_TYPE</td><td>67</td><td>False</td><td>Supplied principalType is not supported</td></tr>
+<tr><td>NON_EMPTY_GROUP</td><td>68</td><td>False</td><td>The group The group is not empty is not empty</td></tr>
+<tr><td>GROUP_ID_NOT_FOUND</td><td>69</td><td>False</td><td>The group id The group id does not exist was not found</td></tr>
+<tr><td>FETCH_SESSION_ID_NOT_FOUND</td><td>70</td><td>True</td><td>The fetch session ID was not found</td></tr>
+<tr><td>INVALID_FETCH_SESSION_EPOCH</td><td>71</td><td>True</td><td>The fetch session epoch is invalid</td></tr>
+</table>
+
diff --git a/11/generated/protocol_messages.html b/11/generated/protocol_messages.html
new file mode 100644
index 0000000..e09afd6
--- /dev/null
+++ b/11/generated/protocol_messages.html
@@ -0,0 +1,4749 @@
+<h5>Headers:</h5>
+<pre>Request Header => api_key api_version correlation_id client_id
+ api_key => INT16
+ api_version => INT16
+ correlation_id => INT32
+ client_id => NULLABLE_STRING
+</pre>
+<table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>api_key</td><td>The id of the request type.</td></tr>
+<tr>
+<td>api_version</td><td>The version of the API.</td></tr>
+<tr>
+<td>correlation_id</td><td>A user-supplied integer value that will be passed back with the response</td></tr>
+<tr>
+<td>client_id</td><td>A user specified identifier for the client making the request.</td></tr>
+</table>
+<pre>Response Header => correlation_id
+ correlation_id => INT32
+</pre>
+<table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>correlation_id</td><td>The user-supplied value passed in with the request</td></tr>
+</table>
+<h5><a name="The_Messages_Produce">Produce API (Key: 0):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>Produce Request (Version: 0) => acks timeout [topic_data]
+ acks => INT16
+ timeout => INT32
+ topic_data => topic [data]
+ topic => STRING
+ data => partition record_set
+ partition => INT32
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>acks</td><td>The number of acknowledgments the producer requires the leader to have received before considering a request complete. Allowed values: 0 for no acknowledgments, 1 for only the leader and -1 for the full ISR.</td></tr>
+<tr>
+<td>timeout</td><td>The time to await a response in ms.</td></tr>
+<tr>
+<td>topic_data</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>data</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Produce Request (Version: 1) => acks timeout [topic_data]
+ acks => INT16
+ timeout => INT32
+ topic_data => topic [data]
+ topic => STRING
+ data => partition record_set
+ partition => INT32
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>acks</td><td>The number of acknowledgments the producer requires the leader to have received before considering a request complete. Allowed values: 0 for no acknowledgments, 1 for only the leader and -1 for the full ISR.</td></tr>
+<tr>
+<td>timeout</td><td>The time to await a response in ms.</td></tr>
+<tr>
+<td>topic_data</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>data</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Produce Request (Version: 2) => acks timeout [topic_data]
+ acks => INT16
+ timeout => INT32
+ topic_data => topic [data]
+ topic => STRING
+ data => partition record_set
+ partition => INT32
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>acks</td><td>The number of acknowledgments the producer requires the leader to have received before considering a request complete. Allowed values: 0 for no acknowledgments, 1 for only the leader and -1 for the full ISR.</td></tr>
+<tr>
+<td>timeout</td><td>The time to await a response in ms.</td></tr>
+<tr>
+<td>topic_data</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>data</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Produce Request (Version: 3) => transactional_id acks timeout [topic_data]
+ transactional_id => NULLABLE_STRING
+ acks => INT16
+ timeout => INT32
+ topic_data => topic [data]
+ topic => STRING
+ data => partition record_set
+ partition => INT32
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transactional_id</td><td>The transactional id or null if the producer is not transactional</td></tr>
+<tr>
+<td>acks</td><td>The number of acknowledgments the producer requires the leader to have received before considering a request complete. Allowed values: 0 for no acknowledgments, 1 for only the leader and -1 for the full ISR.</td></tr>
+<tr>
+<td>timeout</td><td>The time to await a response in ms.</td></tr>
+<tr>
+<td>topic_data</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>data</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Produce Request (Version: 4) => transactional_id acks timeout [topic_data]
+ transactional_id => NULLABLE_STRING
+ acks => INT16
+ timeout => INT32
+ topic_data => topic [data]
+ topic => STRING
+ data => partition record_set
+ partition => INT32
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transactional_id</td><td>The transactional id or null if the producer is not transactional</td></tr>
+<tr>
+<td>acks</td><td>The number of acknowledgments the producer requires the leader to have received before considering a request complete. Allowed values: 0 for no acknowledgments, 1 for only the leader and -1 for the full ISR.</td></tr>
+<tr>
+<td>timeout</td><td>The time to await a response in ms.</td></tr>
+<tr>
+<td>topic_data</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>data</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Produce Request (Version: 5) => transactional_id acks timeout [topic_data]
+ transactional_id => NULLABLE_STRING
+ acks => INT16
+ timeout => INT32
+ topic_data => topic [data]
+ topic => STRING
+ data => partition record_set
+ partition => INT32
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transactional_id</td><td>The transactional id or null if the producer is not transactional</td></tr>
+<tr>
+<td>acks</td><td>The number of acknowledgments the producer requires the leader to have received before considering a request complete. Allowed values: 0 for no acknowledgments, 1 for only the leader and -1 for the full ISR.</td></tr>
+<tr>
+<td>timeout</td><td>The time to await a response in ms.</td></tr>
+<tr>
+<td>topic_data</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>data</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>Produce Response (Version: 0) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code base_offset
+ partition => INT32
+ error_code => INT16
+ base_offset => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>base_offset</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Produce Response (Version: 1) => [responses] throttle_time_ms
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code base_offset
+ partition => INT32
+ error_code => INT16
+ base_offset => INT64
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>base_offset</td><td>null</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<p><pre>Produce Response (Version: 2) => [responses] throttle_time_ms
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code base_offset log_append_time
+ partition => INT32
+ error_code => INT16
+ base_offset => INT64
+ log_append_time => INT64
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>base_offset</td><td>null</td></tr>
+<tr>
+<td>log_append_time</td><td>The timestamp returned by broker after appending the messages. If CreateTime is used for the topic, the timestamp will be -1. If LogAppendTime is used for the topic, the timestamp will be the broker local time when the messages are appended.</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<p><pre>Produce Response (Version: 3) => [responses] throttle_time_ms
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code base_offset log_append_time
+ partition => INT32
+ error_code => INT16
+ base_offset => INT64
+ log_append_time => INT64
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>base_offset</td><td>null</td></tr>
+<tr>
+<td>log_append_time</td><td>The timestamp returned by broker after appending the messages. If CreateTime is used for the topic, the timestamp will be -1. If LogAppendTime is used for the topic, the timestamp will be the broker local time when the messages are appended.</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<p><pre>Produce Response (Version: 4) => [responses] throttle_time_ms
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code base_offset log_append_time
+ partition => INT32
+ error_code => INT16
+ base_offset => INT64
+ log_append_time => INT64
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>base_offset</td><td>null</td></tr>
+<tr>
+<td>log_append_time</td><td>The timestamp returned by broker after appending the messages. If CreateTime is used for the topic, the timestamp will be -1. If LogAppendTime is used for the topic, the timestamp will be the broker local time when the messages are appended.</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<p><pre>Produce Response (Version: 5) => [responses] throttle_time_ms
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code base_offset log_append_time log_start_offset
+ partition => INT32
+ error_code => INT16
+ base_offset => INT64
+ log_append_time => INT64
+ log_start_offset => INT64
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>base_offset</td><td>null</td></tr>
+<tr>
+<td>log_append_time</td><td>The timestamp returned by broker after appending the messages. If CreateTime is used for the topic, the timestamp will be -1. If LogAppendTime is used for the topic, the timestamp will be the broker local time when the messages are appended.</td></tr>
+<tr>
+<td>log_start_offset</td><td>The start offset of the log at the time this produce response was created</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_Fetch">Fetch API (Key: 1):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>Fetch Request (Version: 0) => replica_id max_wait_time min_bytes [topics]
+ replica_id => INT32
+ max_wait_time => INT32
+ min_bytes => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition fetch_offset max_bytes
+ partition => INT32
+ fetch_offset => INT64
+ max_bytes => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>max_wait_time</td><td>Maximum time in ms to wait for the response.</td></tr>
+<tr>
+<td>min_bytes</td><td>Minimum bytes to accumulate in the response.</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>fetch_offset</td><td>Message offset.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to fetch.</td></tr>
+</table>
+</p>
+<p><pre>Fetch Request (Version: 1) => replica_id max_wait_time min_bytes [topics]
+ replica_id => INT32
+ max_wait_time => INT32
+ min_bytes => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition fetch_offset max_bytes
+ partition => INT32
+ fetch_offset => INT64
+ max_bytes => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>max_wait_time</td><td>Maximum time in ms to wait for the response.</td></tr>
+<tr>
+<td>min_bytes</td><td>Minimum bytes to accumulate in the response.</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>fetch_offset</td><td>Message offset.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to fetch.</td></tr>
+</table>
+</p>
+<p><pre>Fetch Request (Version: 2) => replica_id max_wait_time min_bytes [topics]
+ replica_id => INT32
+ max_wait_time => INT32
+ min_bytes => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition fetch_offset max_bytes
+ partition => INT32
+ fetch_offset => INT64
+ max_bytes => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>max_wait_time</td><td>Maximum time in ms to wait for the response.</td></tr>
+<tr>
+<td>min_bytes</td><td>Minimum bytes to accumulate in the response.</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>fetch_offset</td><td>Message offset.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to fetch.</td></tr>
+</table>
+</p>
+<p><pre>Fetch Request (Version: 3) => replica_id max_wait_time min_bytes max_bytes [topics]
+ replica_id => INT32
+ max_wait_time => INT32
+ min_bytes => INT32
+ max_bytes => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition fetch_offset max_bytes
+ partition => INT32
+ fetch_offset => INT64
+ max_bytes => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>max_wait_time</td><td>Maximum time in ms to wait for the response.</td></tr>
+<tr>
+<td>min_bytes</td><td>Minimum bytes to accumulate in the response.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to accumulate in the response. Note that this is not an absolute maximum, if the first message in the first non-empty partition of the fetch is larger than this value, the message will still be returned to ensure that progress can be made.</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch in the order provided.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>fetch_offset</td><td>Message offset.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to fetch.</td></tr>
+</table>
+</p>
+<p><pre>Fetch Request (Version: 4) => replica_id max_wait_time min_bytes max_bytes isolation_level [topics]
+ replica_id => INT32
+ max_wait_time => INT32
+ min_bytes => INT32
+ max_bytes => INT32
+ isolation_level => INT8
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition fetch_offset max_bytes
+ partition => INT32
+ fetch_offset => INT64
+ max_bytes => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>max_wait_time</td><td>Maximum time in ms to wait for the response.</td></tr>
+<tr>
+<td>min_bytes</td><td>Minimum bytes to accumulate in the response.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to accumulate in the response. Note that this is not an absolute maximum, if the first message in the first non-empty partition of the fetch is larger than this value, the message will still be returned to ensure that progress can be made.</td></tr>
+<tr>
+<td>isolation_level</td><td>This setting controls the visibility of transactional records. Using READ_UNCOMMITTED (isolation_level = 0) makes all records visible. With READ_COMMITTED (isolation_level = 1), non-transactional and COMMITTED transactional records are visible. To be more concrete, READ_COMMITTED returns all data from offsets smaller than the current LSO (last stable offset), and enables the inclusion of the list of aborted transactions in the result, which allows consumers to [...]
+<tr>
+<td>topics</td><td>Topics to fetch in the order provided.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>fetch_offset</td><td>Message offset.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to fetch.</td></tr>
+</table>
+</p>
+<p><pre>Fetch Request (Version: 5) => replica_id max_wait_time min_bytes max_bytes isolation_level [topics]
+ replica_id => INT32
+ max_wait_time => INT32
+ min_bytes => INT32
+ max_bytes => INT32
+ isolation_level => INT8
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition fetch_offset log_start_offset max_bytes
+ partition => INT32
+ fetch_offset => INT64
+ log_start_offset => INT64
+ max_bytes => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>max_wait_time</td><td>Maximum time in ms to wait for the response.</td></tr>
+<tr>
+<td>min_bytes</td><td>Minimum bytes to accumulate in the response.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to accumulate in the response. Note that this is not an absolute maximum, if the first message in the first non-empty partition of the fetch is larger than this value, the message will still be returned to ensure that progress can be made.</td></tr>
+<tr>
+<td>isolation_level</td><td>This setting controls the visibility of transactional records. Using READ_UNCOMMITTED (isolation_level = 0) makes all records visible. With READ_COMMITTED (isolation_level = 1), non-transactional and COMMITTED transactional records are visible. To be more concrete, READ_COMMITTED returns all data from offsets smaller than the current LSO (last stable offset), and enables the inclusion of the list of aborted transactions in the result, which allows consumers to [...]
+<tr>
+<td>topics</td><td>Topics to fetch in the order provided.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>fetch_offset</td><td>Message offset.</td></tr>
+<tr>
+<td>log_start_offset</td><td>Earliest available offset of the follower replica. The field is only used when request is sent by follower. </td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to fetch.</td></tr>
+</table>
+</p>
+<p><pre>Fetch Request (Version: 6) => replica_id max_wait_time min_bytes max_bytes isolation_level [topics]
+ replica_id => INT32
+ max_wait_time => INT32
+ min_bytes => INT32
+ max_bytes => INT32
+ isolation_level => INT8
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition fetch_offset log_start_offset max_bytes
+ partition => INT32
+ fetch_offset => INT64
+ log_start_offset => INT64
+ max_bytes => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>max_wait_time</td><td>Maximum time in ms to wait for the response.</td></tr>
+<tr>
+<td>min_bytes</td><td>Minimum bytes to accumulate in the response.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to accumulate in the response. Note that this is not an absolute maximum, if the first message in the first non-empty partition of the fetch is larger than this value, the message will still be returned to ensure that progress can be made.</td></tr>
+<tr>
+<td>isolation_level</td><td>This setting controls the visibility of transactional records. Using READ_UNCOMMITTED (isolation_level = 0) makes all records visible. With READ_COMMITTED (isolation_level = 1), non-transactional and COMMITTED transactional records are visible. To be more concrete, READ_COMMITTED returns all data from offsets smaller than the current LSO (last stable offset), and enables the inclusion of the list of aborted transactions in the result, which allows consumers to [...]
+<tr>
+<td>topics</td><td>Topics to fetch in the order provided.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>fetch_offset</td><td>Message offset.</td></tr>
+<tr>
+<td>log_start_offset</td><td>Earliest available offset of the follower replica. The field is only used when request is sent by follower. </td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to fetch.</td></tr>
+</table>
+</p>
+<p><pre>Fetch Request (Version: 7) => replica_id max_wait_time min_bytes max_bytes isolation_level session_id epoch [topics] [forgetten_topics_data]
+ replica_id => INT32
+ max_wait_time => INT32
+ min_bytes => INT32
+ max_bytes => INT32
+ isolation_level => INT8
+ session_id => INT32
+ epoch => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition fetch_offset log_start_offset max_bytes
+ partition => INT32
+ fetch_offset => INT64
+ log_start_offset => INT64
+ max_bytes => INT32
+ forgetten_topics_data => topic [partitions]
+ topic => STRING
+ partitions => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>max_wait_time</td><td>Maximum time in ms to wait for the response.</td></tr>
+<tr>
+<td>min_bytes</td><td>Minimum bytes to accumulate in the response.</td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to accumulate in the response. Note that this is not an absolute maximum, if the first message in the first non-empty partition of the fetch is larger than this value, the message will still be returned to ensure that progress can be made.</td></tr>
+<tr>
+<td>isolation_level</td><td>This setting controls the visibility of transactional records. Using READ_UNCOMMITTED (isolation_level = 0) makes all records visible. With READ_COMMITTED (isolation_level = 1), non-transactional and COMMITTED transactional records are visible. To be more concrete, READ_COMMITTED returns all data from offsets smaller than the current LSO (last stable offset), and enables the inclusion of the list of aborted transactions in the result, which allows consumers to [...]
+<tr>
+<td>session_id</td><td>The fetch session ID</td></tr>
+<tr>
+<td>epoch</td><td>The fetch epoch</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch in the order provided.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>fetch_offset</td><td>Message offset.</td></tr>
+<tr>
+<td>log_start_offset</td><td>Earliest available offset of the follower replica. The field is only used when request is sent by follower. </td></tr>
+<tr>
+<td>max_bytes</td><td>Maximum bytes to fetch.</td></tr>
+<tr>
+<td>forgetten_topics_data</td><td>Topics to remove from the fetch session.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to remove from the fetch session.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>Fetch Response (Version: 0) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition_header record_set
+ partition_header => partition error_code high_watermark
+ partition => INT32
+ error_code => INT16
+ high_watermark => INT64
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition_header</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>high_watermark</td><td>Last committed offset.</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Fetch Response (Version: 1) => throttle_time_ms [responses]
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition_header record_set
+ partition_header => partition error_code high_watermark
+ partition => INT32
+ error_code => INT16
+ high_watermark => INT64
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition_header</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>high_watermark</td><td>Last committed offset.</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Fetch Response (Version: 2) => throttle_time_ms [responses]
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition_header record_set
+ partition_header => partition error_code high_watermark
+ partition => INT32
+ error_code => INT16
+ high_watermark => INT64
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition_header</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>high_watermark</td><td>Last committed offset.</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Fetch Response (Version: 3) => throttle_time_ms [responses]
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition_header record_set
+ partition_header => partition error_code high_watermark
+ partition => INT32
+ error_code => INT16
+ high_watermark => INT64
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition_header</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>high_watermark</td><td>Last committed offset.</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Fetch Response (Version: 4) => throttle_time_ms [responses]
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition_header record_set
+ partition_header => partition error_code high_watermark last_stable_offset [aborted_transactions]
+ partition => INT32
+ error_code => INT16
+ high_watermark => INT64
+ last_stable_offset => INT64
+ aborted_transactions => producer_id first_offset
+ producer_id => INT64
+ first_offset => INT64
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition_header</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>high_watermark</td><td>Last committed offset.</td></tr>
+<tr>
+<td>last_stable_offset</td><td>The last stable offset (or LSO) of the partition. This is the last offset such that the state of all transactional records prior to this offset have been decided (ABORTED or COMMITTED)</td></tr>
+<tr>
+<td>aborted_transactions</td><td>null</td></tr>
+<tr>
+<td>producer_id</td><td>The producer id associated with the aborted transactions</td></tr>
+<tr>
+<td>first_offset</td><td>The first offset in the aborted transaction</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Fetch Response (Version: 5) => throttle_time_ms [responses]
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition_header record_set
+ partition_header => partition error_code high_watermark last_stable_offset log_start_offset [aborted_transactions]
+ partition => INT32
+ error_code => INT16
+ high_watermark => INT64
+ last_stable_offset => INT64
+ log_start_offset => INT64
+ aborted_transactions => producer_id first_offset
+ producer_id => INT64
+ first_offset => INT64
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition_header</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>high_watermark</td><td>Last committed offset.</td></tr>
+<tr>
+<td>last_stable_offset</td><td>The last stable offset (or LSO) of the partition. This is the last offset such that the state of all transactional records prior to this offset have been decided (ABORTED or COMMITTED)</td></tr>
+<tr>
+<td>log_start_offset</td><td>Earliest available offset.</td></tr>
+<tr>
+<td>aborted_transactions</td><td>null</td></tr>
+<tr>
+<td>producer_id</td><td>The producer id associated with the aborted transactions</td></tr>
+<tr>
+<td>first_offset</td><td>The first offset in the aborted transaction</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Fetch Response (Version: 6) => throttle_time_ms [responses]
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition_header record_set
+ partition_header => partition error_code high_watermark last_stable_offset log_start_offset [aborted_transactions]
+ partition => INT32
+ error_code => INT16
+ high_watermark => INT64
+ last_stable_offset => INT64
+ log_start_offset => INT64
+ aborted_transactions => producer_id first_offset
+ producer_id => INT64
+ first_offset => INT64
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition_header</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>high_watermark</td><td>Last committed offset.</td></tr>
+<tr>
+<td>last_stable_offset</td><td>The last stable offset (or LSO) of the partition. This is the last offset such that the state of all transactional records prior to this offset have been decided (ABORTED or COMMITTED)</td></tr>
+<tr>
+<td>log_start_offset</td><td>Earliest available offset.</td></tr>
+<tr>
+<td>aborted_transactions</td><td>null</td></tr>
+<tr>
+<td>producer_id</td><td>The producer id associated with the aborted transactions</td></tr>
+<tr>
+<td>first_offset</td><td>The first offset in the aborted transaction</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>Fetch Response (Version: 7) => throttle_time_ms error_code session_id [responses]
+ throttle_time_ms => INT32
+ error_code => INT16
+ session_id => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition_header record_set
+ partition_header => partition error_code high_watermark last_stable_offset log_start_offset [aborted_transactions]
+ partition => INT32
+ error_code => INT16
+ high_watermark => INT64
+ last_stable_offset => INT64
+ log_start_offset => INT64
+ aborted_transactions => producer_id first_offset
+ producer_id => INT64
+ first_offset => INT64
+ record_set => RECORDS
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>session_id</td><td>The fetch session ID</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition_header</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>high_watermark</td><td>Last committed offset.</td></tr>
+<tr>
+<td>last_stable_offset</td><td>The last stable offset (or LSO) of the partition. This is the last offset such that the state of all transactional records prior to this offset have been decided (ABORTED or COMMITTED)</td></tr>
+<tr>
+<td>log_start_offset</td><td>Earliest available offset.</td></tr>
+<tr>
+<td>aborted_transactions</td><td>null</td></tr>
+<tr>
+<td>producer_id</td><td>The producer id associated with the aborted transactions</td></tr>
+<tr>
+<td>first_offset</td><td>The first offset in the aborted transaction</td></tr>
+<tr>
+<td>record_set</td><td>null</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_ListOffsets">ListOffsets API (Key: 2):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>ListOffsets Request (Version: 0) => replica_id [topics]
+ replica_id => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition timestamp max_num_offsets
+ partition => INT32
+ timestamp => INT64
+ max_num_offsets => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>topics</td><td>Topics to list offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to list offset.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>timestamp</td><td>Timestamp.</td></tr>
+<tr>
+<td>max_num_offsets</td><td>Maximum offsets to return.</td></tr>
+</table>
+</p>
+<p><pre>ListOffsets Request (Version: 1) => replica_id [topics]
+ replica_id => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition timestamp
+ partition => INT32
+ timestamp => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>topics</td><td>Topics to list offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to list offset.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>timestamp</td><td>The target timestamp for the partition.</td></tr>
+</table>
+</p>
+<p><pre>ListOffsets Request (Version: 2) => replica_id isolation_level [topics]
+ replica_id => INT32
+ isolation_level => INT8
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition timestamp
+ partition => INT32
+ timestamp => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>replica_id</td><td>Broker id of the follower. For normal consumers, use -1.</td></tr>
+<tr>
+<td>isolation_level</td><td>This setting controls the visibility of transactional records. Using READ_UNCOMMITTED (isolation_level = 0) makes all records visible. With READ_COMMITTED (isolation_level = 1), non-transactional and COMMITTED transactional records are visible. To be more concrete, READ_COMMITTED returns all data from offsets smaller than the current LSO (last stable offset), and enables the inclusion of the list of aborted transactions in the result, which allows consumers to [...]
+<tr>
+<td>topics</td><td>Topics to list offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to list offset.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>timestamp</td><td>The target timestamp for the partition.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>ListOffsets Response (Version: 0) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code [offsets]
+ partition => INT32
+ error_code => INT16
+ offsets => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>offsets</td><td>A list of offsets.</td></tr>
+</table>
+</p>
+<p><pre>ListOffsets Response (Version: 1) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code timestamp offset
+ partition => INT32
+ error_code => INT16
+ timestamp => INT64
+ offset => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>timestamp</td><td>The timestamp associated with the returned offset</td></tr>
+<tr>
+<td>offset</td><td>offset found</td></tr>
+</table>
+</p>
+<p><pre>ListOffsets Response (Version: 2) => throttle_time_ms [responses]
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code timestamp offset
+ partition => INT32
+ error_code => INT16
+ timestamp => INT64
+ offset => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>timestamp</td><td>The timestamp associated with the returned offset</td></tr>
+<tr>
+<td>offset</td><td>offset found</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_Metadata">Metadata API (Key: 3):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>Metadata Request (Version: 0) => [topics]
+ topics => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to fetch metadata for. If no topics are specified fetch metadata for all topics.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Request (Version: 1) => [topics]
+ topics => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to fetch metadata for. If the topics array is null fetch metadata for all topics.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Request (Version: 2) => [topics]
+ topics => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to fetch metadata for. If the topics array is null fetch metadata for all topics.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Request (Version: 3) => [topics]
+ topics => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to fetch metadata for. If the topics array is null fetch metadata for all topics.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Request (Version: 4) => [topics] allow_auto_topic_creation
+ topics => STRING
+ allow_auto_topic_creation => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to fetch metadata for. If the topics array is null fetch metadata for all topics.</td></tr>
+<tr>
+<td>allow_auto_topic_creation</td><td>If this and the broker config 'auto.create.topics.enable' are true, topics that don't exist will be created by the broker. Otherwise, no topics will be created by the broker.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Request (Version: 5) => [topics] allow_auto_topic_creation
+ topics => STRING
+ allow_auto_topic_creation => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to fetch metadata for. If the topics array is null fetch metadata for all topics.</td></tr>
+<tr>
+<td>allow_auto_topic_creation</td><td>If this and the broker config 'auto.create.topics.enable' are true, topics that don't exist will be created by the broker. Otherwise, no topics will be created by the broker.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>Metadata Response (Version: 0) => [brokers] [topic_metadata]
+ brokers => node_id host port
+ node_id => INT32
+ host => STRING
+ port => INT32
+ topic_metadata => error_code topic [partition_metadata]
+ error_code => INT16
+ topic => STRING
+ partition_metadata => error_code partition leader [replicas] [isr]
+ error_code => INT16
+ partition => INT32
+ leader => INT32
+ replicas => INT32
+ isr => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>brokers</td><td>Host and port information for all brokers.</td></tr>
+<tr>
+<td>node_id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>topic_metadata</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_metadata</td><td>Metadata for each partition of the topic.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>leader</td><td>The id of the broker acting as leader for this partition.</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that host this partition.</td></tr>
+<tr>
+<td>isr</td><td>The set of nodes that are in sync with the leader for this partition.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Response (Version: 1) => [brokers] controller_id [topic_metadata]
+ brokers => node_id host port rack
+ node_id => INT32
+ host => STRING
+ port => INT32
+ rack => NULLABLE_STRING
+ controller_id => INT32
+ topic_metadata => error_code topic is_internal [partition_metadata]
+ error_code => INT16
+ topic => STRING
+ is_internal => BOOLEAN
+ partition_metadata => error_code partition leader [replicas] [isr]
+ error_code => INT16
+ partition => INT32
+ leader => INT32
+ replicas => INT32
+ isr => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>brokers</td><td>Host and port information for all brokers.</td></tr>
+<tr>
+<td>node_id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>rack</td><td>The rack of the broker.</td></tr>
+<tr>
+<td>controller_id</td><td>The broker id of the controller broker.</td></tr>
+<tr>
+<td>topic_metadata</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>is_internal</td><td>Indicates if the topic is considered a Kafka internal topic</td></tr>
+<tr>
+<td>partition_metadata</td><td>Metadata for each partition of the topic.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>leader</td><td>The id of the broker acting as leader for this partition.</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that host this partition.</td></tr>
+<tr>
+<td>isr</td><td>The set of nodes that are in sync with the leader for this partition.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Response (Version: 2) => [brokers] cluster_id controller_id [topic_metadata]
+ brokers => node_id host port rack
+ node_id => INT32
+ host => STRING
+ port => INT32
+ rack => NULLABLE_STRING
+ cluster_id => NULLABLE_STRING
+ controller_id => INT32
+ topic_metadata => error_code topic is_internal [partition_metadata]
+ error_code => INT16
+ topic => STRING
+ is_internal => BOOLEAN
+ partition_metadata => error_code partition leader [replicas] [isr]
+ error_code => INT16
+ partition => INT32
+ leader => INT32
+ replicas => INT32
+ isr => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>brokers</td><td>Host and port information for all brokers.</td></tr>
+<tr>
+<td>node_id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>rack</td><td>The rack of the broker.</td></tr>
+<tr>
+<td>cluster_id</td><td>The cluster id that this broker belongs to.</td></tr>
+<tr>
+<td>controller_id</td><td>The broker id of the controller broker.</td></tr>
+<tr>
+<td>topic_metadata</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>is_internal</td><td>Indicates if the topic is considered a Kafka internal topic</td></tr>
+<tr>
+<td>partition_metadata</td><td>Metadata for each partition of the topic.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>leader</td><td>The id of the broker acting as leader for this partition.</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that host this partition.</td></tr>
+<tr>
+<td>isr</td><td>The set of nodes that are in sync with the leader for this partition.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Response (Version: 3) => throttle_time_ms [brokers] cluster_id controller_id [topic_metadata]
+ throttle_time_ms => INT32
+ brokers => node_id host port rack
+ node_id => INT32
+ host => STRING
+ port => INT32
+ rack => NULLABLE_STRING
+ cluster_id => NULLABLE_STRING
+ controller_id => INT32
+ topic_metadata => error_code topic is_internal [partition_metadata]
+ error_code => INT16
+ topic => STRING
+ is_internal => BOOLEAN
+ partition_metadata => error_code partition leader [replicas] [isr]
+ error_code => INT16
+ partition => INT32
+ leader => INT32
+ replicas => INT32
+ isr => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>brokers</td><td>Host and port information for all brokers.</td></tr>
+<tr>
+<td>node_id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>rack</td><td>The rack of the broker.</td></tr>
+<tr>
+<td>cluster_id</td><td>The cluster id that this broker belongs to.</td></tr>
+<tr>
+<td>controller_id</td><td>The broker id of the controller broker.</td></tr>
+<tr>
+<td>topic_metadata</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>is_internal</td><td>Indicates if the topic is considered a Kafka internal topic</td></tr>
+<tr>
+<td>partition_metadata</td><td>Metadata for each partition of the topic.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>leader</td><td>The id of the broker acting as leader for this partition.</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that host this partition.</td></tr>
+<tr>
+<td>isr</td><td>The set of nodes that are in sync with the leader for this partition.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Response (Version: 4) => throttle_time_ms [brokers] cluster_id controller_id [topic_metadata]
+ throttle_time_ms => INT32
+ brokers => node_id host port rack
+ node_id => INT32
+ host => STRING
+ port => INT32
+ rack => NULLABLE_STRING
+ cluster_id => NULLABLE_STRING
+ controller_id => INT32
+ topic_metadata => error_code topic is_internal [partition_metadata]
+ error_code => INT16
+ topic => STRING
+ is_internal => BOOLEAN
+ partition_metadata => error_code partition leader [replicas] [isr]
+ error_code => INT16
+ partition => INT32
+ leader => INT32
+ replicas => INT32
+ isr => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>brokers</td><td>Host and port information for all brokers.</td></tr>
+<tr>
+<td>node_id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>rack</td><td>The rack of the broker.</td></tr>
+<tr>
+<td>cluster_id</td><td>The cluster id that this broker belongs to.</td></tr>
+<tr>
+<td>controller_id</td><td>The broker id of the controller broker.</td></tr>
+<tr>
+<td>topic_metadata</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>is_internal</td><td>Indicates if the topic is considered a Kafka internal topic</td></tr>
+<tr>
+<td>partition_metadata</td><td>Metadata for each partition of the topic.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>leader</td><td>The id of the broker acting as leader for this partition.</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that host this partition.</td></tr>
+<tr>
+<td>isr</td><td>The set of nodes that are in sync with the leader for this partition.</td></tr>
+</table>
+</p>
+<p><pre>Metadata Response (Version: 5) => throttle_time_ms [brokers] cluster_id controller_id [topic_metadata]
+ throttle_time_ms => INT32
+ brokers => node_id host port rack
+ node_id => INT32
+ host => STRING
+ port => INT32
+ rack => NULLABLE_STRING
+ cluster_id => NULLABLE_STRING
+ controller_id => INT32
+ topic_metadata => error_code topic is_internal [partition_metadata]
+ error_code => INT16
+ topic => STRING
+ is_internal => BOOLEAN
+ partition_metadata => error_code partition leader [replicas] [isr] [offline_replicas]
+ error_code => INT16
+ partition => INT32
+ leader => INT32
+ replicas => INT32
+ isr => INT32
+ offline_replicas => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>brokers</td><td>Host and port information for all brokers.</td></tr>
+<tr>
+<td>node_id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>rack</td><td>The rack of the broker.</td></tr>
+<tr>
+<td>cluster_id</td><td>The cluster id that this broker belongs to.</td></tr>
+<tr>
+<td>controller_id</td><td>The broker id of the controller broker.</td></tr>
+<tr>
+<td>topic_metadata</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>is_internal</td><td>Indicates if the topic is considered a Kafka internal topic</td></tr>
+<tr>
+<td>partition_metadata</td><td>Metadata for each partition of the topic.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>leader</td><td>The id of the broker acting as leader for this partition.</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that host this partition.</td></tr>
+<tr>
+<td>isr</td><td>The set of nodes that are in sync with the leader for this partition.</td></tr>
+<tr>
+<td>offline_replicas</td><td>The set of offline replicas of this partition.</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_LeaderAndIsr">LeaderAndIsr API (Key: 4):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>LeaderAndIsr Request (Version: 0) => controller_id controller_epoch [partition_states] [live_leaders]
+ controller_id => INT32
+ controller_epoch => INT32
+ partition_states => topic partition controller_epoch leader leader_epoch [isr] zk_version [replicas]
+ topic => STRING
+ partition => INT32
+ controller_epoch => INT32
+ leader => INT32
+ leader_epoch => INT32
+ isr => INT32
+ zk_version => INT32
+ replicas => INT32
+ live_leaders => id host port
+ id => INT32
+ host => STRING
+ port => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>controller_id</td><td>The controller id.</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>partition_states</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>leader</td><td>The broker id for the leader.</td></tr>
+<tr>
+<td>leader_epoch</td><td>The leader epoch.</td></tr>
+<tr>
+<td>isr</td><td>The in sync replica ids.</td></tr>
+<tr>
+<td>zk_version</td><td>The ZK version.</td></tr>
+<tr>
+<td>replicas</td><td>The replica ids.</td></tr>
+<tr>
+<td>live_leaders</td><td>null</td></tr>
+<tr>
+<td>id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+</table>
+</p>
+<p><pre>LeaderAndIsr Request (Version: 1) => controller_id controller_epoch [partition_states] [live_leaders]
+ controller_id => INT32
+ controller_epoch => INT32
+ partition_states => topic partition controller_epoch leader leader_epoch [isr] zk_version [replicas] is_new
+ topic => STRING
+ partition => INT32
+ controller_epoch => INT32
+ leader => INT32
+ leader_epoch => INT32
+ isr => INT32
+ zk_version => INT32
+ replicas => INT32
+ is_new => BOOLEAN
+ live_leaders => id host port
+ id => INT32
+ host => STRING
+ port => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>controller_id</td><td>The controller id.</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>partition_states</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>leader</td><td>The broker id for the leader.</td></tr>
+<tr>
+<td>leader_epoch</td><td>The leader epoch.</td></tr>
+<tr>
+<td>isr</td><td>The in sync replica ids.</td></tr>
+<tr>
+<td>zk_version</td><td>The ZK version.</td></tr>
+<tr>
+<td>replicas</td><td>The replica ids.</td></tr>
+<tr>
+<td>is_new</td><td>Whether the replica should have existed on the broker or not</td></tr>
+<tr>
+<td>live_leaders</td><td>null</td></tr>
+<tr>
+<td>id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>LeaderAndIsr Response (Version: 0) => error_code [partitions]
+ error_code => INT16
+ partitions => topic partition error_code
+ topic => STRING
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>LeaderAndIsr Response (Version: 1) => error_code [partitions]
+ error_code => INT16
+ partitions => topic partition error_code
+ topic => STRING
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_StopReplica">StopReplica API (Key: 5):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>StopReplica Request (Version: 0) => controller_id controller_epoch delete_partitions [partitions]
+ controller_id => INT32
+ controller_epoch => INT32
+ delete_partitions => BOOLEAN
+ partitions => topic partition
+ topic => STRING
+ partition => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>controller_id</td><td>The controller id.</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>delete_partitions</td><td>Boolean which indicates if replica's partitions must be deleted.</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>StopReplica Response (Version: 0) => error_code [partitions]
+ error_code => INT16
+ partitions => topic partition error_code
+ topic => STRING
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_UpdateMetadata">UpdateMetadata API (Key: 6):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>UpdateMetadata Request (Version: 0) => controller_id controller_epoch [partition_states] [live_brokers]
+ controller_id => INT32
+ controller_epoch => INT32
+ partition_states => topic partition controller_epoch leader leader_epoch [isr] zk_version [replicas]
+ topic => STRING
+ partition => INT32
+ controller_epoch => INT32
+ leader => INT32
+ leader_epoch => INT32
+ isr => INT32
+ zk_version => INT32
+ replicas => INT32
+ live_brokers => id host port
+ id => INT32
+ host => STRING
+ port => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>controller_id</td><td>The controller id.</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>partition_states</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>leader</td><td>The broker id for the leader.</td></tr>
+<tr>
+<td>leader_epoch</td><td>The leader epoch.</td></tr>
+<tr>
+<td>isr</td><td>The in sync replica ids.</td></tr>
+<tr>
+<td>zk_version</td><td>The ZK version.</td></tr>
+<tr>
+<td>replicas</td><td>The replica ids.</td></tr>
+<tr>
+<td>live_brokers</td><td>null</td></tr>
+<tr>
+<td>id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+</table>
+</p>
+<p><pre>UpdateMetadata Request (Version: 1) => controller_id controller_epoch [partition_states] [live_brokers]
+ controller_id => INT32
+ controller_epoch => INT32
+ partition_states => topic partition controller_epoch leader leader_epoch [isr] zk_version [replicas]
+ topic => STRING
+ partition => INT32
+ controller_epoch => INT32
+ leader => INT32
+ leader_epoch => INT32
+ isr => INT32
+ zk_version => INT32
+ replicas => INT32
+ live_brokers => id [end_points]
+ id => INT32
+ end_points => port host security_protocol_type
+ port => INT32
+ host => STRING
+ security_protocol_type => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>controller_id</td><td>The controller id.</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>partition_states</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>leader</td><td>The broker id for the leader.</td></tr>
+<tr>
+<td>leader_epoch</td><td>The leader epoch.</td></tr>
+<tr>
+<td>isr</td><td>The in sync replica ids.</td></tr>
+<tr>
+<td>zk_version</td><td>The ZK version.</td></tr>
+<tr>
+<td>replicas</td><td>The replica ids.</td></tr>
+<tr>
+<td>live_brokers</td><td>null</td></tr>
+<tr>
+<td>id</td><td>The broker id.</td></tr>
+<tr>
+<td>end_points</td><td>null</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>security_protocol_type</td><td>The security protocol type.</td></tr>
+</table>
+</p>
+<p><pre>UpdateMetadata Request (Version: 2) => controller_id controller_epoch [partition_states] [live_brokers]
+ controller_id => INT32
+ controller_epoch => INT32
+ partition_states => topic partition controller_epoch leader leader_epoch [isr] zk_version [replicas]
+ topic => STRING
+ partition => INT32
+ controller_epoch => INT32
+ leader => INT32
+ leader_epoch => INT32
+ isr => INT32
+ zk_version => INT32
+ replicas => INT32
+ live_brokers => id [end_points] rack
+ id => INT32
+ end_points => port host security_protocol_type
+ port => INT32
+ host => STRING
+ security_protocol_type => INT16
+ rack => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>controller_id</td><td>The controller id.</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>partition_states</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>leader</td><td>The broker id for the leader.</td></tr>
+<tr>
+<td>leader_epoch</td><td>The leader epoch.</td></tr>
+<tr>
+<td>isr</td><td>The in sync replica ids.</td></tr>
+<tr>
+<td>zk_version</td><td>The ZK version.</td></tr>
+<tr>
+<td>replicas</td><td>The replica ids.</td></tr>
+<tr>
+<td>live_brokers</td><td>null</td></tr>
+<tr>
+<td>id</td><td>The broker id.</td></tr>
+<tr>
+<td>end_points</td><td>null</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>security_protocol_type</td><td>The security protocol type.</td></tr>
+<tr>
+<td>rack</td><td>The rack</td></tr>
+</table>
+</p>
+<p><pre>UpdateMetadata Request (Version: 3) => controller_id controller_epoch [partition_states] [live_brokers]
+ controller_id => INT32
+ controller_epoch => INT32
+ partition_states => topic partition controller_epoch leader leader_epoch [isr] zk_version [replicas]
+ topic => STRING
+ partition => INT32
+ controller_epoch => INT32
+ leader => INT32
+ leader_epoch => INT32
+ isr => INT32
+ zk_version => INT32
+ replicas => INT32
+ live_brokers => id [end_points] rack
+ id => INT32
+ end_points => port host listener_name security_protocol_type
+ port => INT32
+ host => STRING
+ listener_name => STRING
+ security_protocol_type => INT16
+ rack => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>controller_id</td><td>The controller id.</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>partition_states</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>leader</td><td>The broker id for the leader.</td></tr>
+<tr>
+<td>leader_epoch</td><td>The leader epoch.</td></tr>
+<tr>
+<td>isr</td><td>The in sync replica ids.</td></tr>
+<tr>
+<td>zk_version</td><td>The ZK version.</td></tr>
+<tr>
+<td>replicas</td><td>The replica ids.</td></tr>
+<tr>
+<td>live_brokers</td><td>null</td></tr>
+<tr>
+<td>id</td><td>The broker id.</td></tr>
+<tr>
+<td>end_points</td><td>null</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>listener_name</td><td>The listener name.</td></tr>
+<tr>
+<td>security_protocol_type</td><td>The security protocol type.</td></tr>
+<tr>
+<td>rack</td><td>The rack</td></tr>
+</table>
+</p>
+<p><pre>UpdateMetadata Request (Version: 4) => controller_id controller_epoch [partition_states] [live_brokers]
+ controller_id => INT32
+ controller_epoch => INT32
+ partition_states => topic partition controller_epoch leader leader_epoch [isr] zk_version [replicas] [offline_replicas]
+ topic => STRING
+ partition => INT32
+ controller_epoch => INT32
+ leader => INT32
+ leader_epoch => INT32
+ isr => INT32
+ zk_version => INT32
+ replicas => INT32
+ offline_replicas => INT32
+ live_brokers => id [end_points] rack
+ id => INT32
+ end_points => port host listener_name security_protocol_type
+ port => INT32
+ host => STRING
+ listener_name => STRING
+ security_protocol_type => INT16
+ rack => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>controller_id</td><td>The controller id.</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>partition_states</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>controller_epoch</td><td>The controller epoch.</td></tr>
+<tr>
+<td>leader</td><td>The broker id for the leader.</td></tr>
+<tr>
+<td>leader_epoch</td><td>The leader epoch.</td></tr>
+<tr>
+<td>isr</td><td>The in sync replica ids.</td></tr>
+<tr>
+<td>zk_version</td><td>The ZK version.</td></tr>
+<tr>
+<td>replicas</td><td>The replica ids.</td></tr>
+<tr>
+<td>offline_replicas</td><td>The offline replica ids</td></tr>
+<tr>
+<td>live_brokers</td><td>null</td></tr>
+<tr>
+<td>id</td><td>The broker id.</td></tr>
+<tr>
+<td>end_points</td><td>null</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>listener_name</td><td>The listener name.</td></tr>
+<tr>
+<td>security_protocol_type</td><td>The security protocol type.</td></tr>
+<tr>
+<td>rack</td><td>The rack</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>UpdateMetadata Response (Version: 0) => error_code
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>UpdateMetadata Response (Version: 1) => error_code
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>UpdateMetadata Response (Version: 2) => error_code
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>UpdateMetadata Response (Version: 3) => error_code
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>UpdateMetadata Response (Version: 4) => error_code
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_ControlledShutdown">ControlledShutdown API (Key: 7):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>ControlledShutdown Request (Version: 0) => broker_id
+ broker_id => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>broker_id</td><td>The id of the broker for which controlled shutdown has been requested.</td></tr>
+</table>
+</p>
+<p><pre>ControlledShutdown Request (Version: 1) => broker_id
+ broker_id => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>broker_id</td><td>The id of the broker for which controlled shutdown has been requested.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>ControlledShutdown Response (Version: 0) => error_code [partitions_remaining]
+ error_code => INT16
+ partitions_remaining => topic partition
+ topic => STRING
+ partition => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partitions_remaining</td><td>The partitions that the broker still leads.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+</table>
+</p>
+<p><pre>ControlledShutdown Response (Version: 1) => error_code [partitions_remaining]
+ error_code => INT16
+ partitions_remaining => topic partition
+ topic => STRING
+ partition => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partitions_remaining</td><td>The partitions that the broker still leads.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_OffsetCommit">OffsetCommit API (Key: 8):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>OffsetCommit Request (Version: 0) => group_id [topics]
+ group_id => STRING
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition offset metadata
+ partition => INT32
+ offset => INT64
+ metadata => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>topics</td><td>Topics to commit offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to commit offsets.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>Message offset to be committed.</td></tr>
+<tr>
+<td>metadata</td><td>Any associated metadata the client wants to keep.</td></tr>
+</table>
+</p>
+<p><pre>OffsetCommit Request (Version: 1) => group_id generation_id member_id [topics]
+ group_id => STRING
+ generation_id => INT32
+ member_id => STRING
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition offset timestamp metadata
+ partition => INT32
+ offset => INT64
+ timestamp => INT64
+ metadata => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>topics</td><td>Topics to commit offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to commit offsets.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>Message offset to be committed.</td></tr>
+<tr>
+<td>timestamp</td><td>Timestamp of the commit</td></tr>
+<tr>
+<td>metadata</td><td>Any associated metadata the client wants to keep.</td></tr>
+</table>
+</p>
+<p><pre>OffsetCommit Request (Version: 2) => group_id generation_id member_id retention_time [topics]
+ group_id => STRING
+ generation_id => INT32
+ member_id => STRING
+ retention_time => INT64
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition offset metadata
+ partition => INT32
+ offset => INT64
+ metadata => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>retention_time</td><td>Time period in ms to retain the offset.</td></tr>
+<tr>
+<td>topics</td><td>Topics to commit offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to commit offsets.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>Message offset to be committed.</td></tr>
+<tr>
+<td>metadata</td><td>Any associated metadata the client wants to keep.</td></tr>
+</table>
+</p>
+<p><pre>OffsetCommit Request (Version: 3) => group_id generation_id member_id retention_time [topics]
+ group_id => STRING
+ generation_id => INT32
+ member_id => STRING
+ retention_time => INT64
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition offset metadata
+ partition => INT32
+ offset => INT64
+ metadata => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>retention_time</td><td>Time period in ms to retain the offset.</td></tr>
+<tr>
+<td>topics</td><td>Topics to commit offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to commit offsets.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>Message offset to be committed.</td></tr>
+<tr>
+<td>metadata</td><td>Any associated metadata the client wants to keep.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>OffsetCommit Response (Version: 0) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>OffsetCommit Response (Version: 1) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>OffsetCommit Response (Version: 2) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>OffsetCommit Response (Version: 3) => throttle_time_ms [responses]
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition error_code
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_OffsetFetch">OffsetFetch API (Key: 9):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>OffsetFetch Request (Version: 0) => group_id [topics]
+ group_id => STRING
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition
+ partition => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch offsets.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+</table>
+</p>
+<p><pre>OffsetFetch Request (Version: 1) => group_id [topics]
+ group_id => STRING
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition
+ partition => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch offsets.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch offsets.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+</table>
+</p>
+<p><pre>OffsetFetch Request (Version: 2) => group_id [topics]
+ group_id => STRING
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition
+ partition => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch offsets. If the topic array is null fetch offsets for all topics.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch offsets.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+</table>
+</p>
+<p><pre>OffsetFetch Request (Version: 3) => group_id [topics]
+ group_id => STRING
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition
+ partition => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>topics</td><td>Topics to fetch offsets. If the topic array is null fetch offsets for all topics.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>Partitions to fetch offsets.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>OffsetFetch Response (Version: 0) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition offset metadata error_code
+ partition => INT32
+ offset => INT64
+ metadata => NULLABLE_STRING
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>Last committed message offset.</td></tr>
+<tr>
+<td>metadata</td><td>Any associated metadata the client wants to keep.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>OffsetFetch Response (Version: 1) => [responses]
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition offset metadata error_code
+ partition => INT32
+ offset => INT64
+ metadata => NULLABLE_STRING
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>Last committed message offset.</td></tr>
+<tr>
+<td>metadata</td><td>Any associated metadata the client wants to keep.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>OffsetFetch Response (Version: 2) => [responses] error_code
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition offset metadata error_code
+ partition => INT32
+ offset => INT64
+ metadata => NULLABLE_STRING
+ error_code => INT16
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>Last committed message offset.</td></tr>
+<tr>
+<td>metadata</td><td>Any associated metadata the client wants to keep.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>OffsetFetch Response (Version: 3) => throttle_time_ms [responses] error_code
+ throttle_time_ms => INT32
+ responses => topic [partition_responses]
+ topic => STRING
+ partition_responses => partition offset metadata error_code
+ partition => INT32
+ offset => INT64
+ metadata => NULLABLE_STRING
+ error_code => INT16
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>responses</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_responses</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>Last committed message offset.</td></tr>
+<tr>
+<td>metadata</td><td>Any associated metadata the client wants to keep.</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_FindCoordinator">FindCoordinator API (Key: 10):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>FindCoordinator Request (Version: 0) => group_id
+ group_id => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+</table>
+</p>
+<p><pre>FindCoordinator Request (Version: 1) => coordinator_key coordinator_type
+ coordinator_key => STRING
+ coordinator_type => INT8
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>coordinator_key</td><td>Id to use for finding the coordinator (for groups, this is the groupId, for transactional producers, this is the transactional id)</td></tr>
+<tr>
+<td>coordinator_type</td><td>The type of coordinator to find (0 = group, 1 = transaction)</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>FindCoordinator Response (Version: 0) => error_code coordinator
+ error_code => INT16
+ coordinator => node_id host port
+ node_id => INT32
+ host => STRING
+ port => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>coordinator</td><td>Host and port information for the coordinator for a consumer group.</td></tr>
+<tr>
+<td>node_id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+</table>
+</p>
+<p><pre>FindCoordinator Response (Version: 1) => throttle_time_ms error_code error_message coordinator
+ throttle_time_ms => INT32
+ error_code => INT16
+ error_message => NULLABLE_STRING
+ coordinator => node_id host port
+ node_id => INT32
+ host => STRING
+ port => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+<tr>
+<td>coordinator</td><td>Host and port information for the coordinator</td></tr>
+<tr>
+<td>node_id</td><td>The broker id.</td></tr>
+<tr>
+<td>host</td><td>The hostname of the broker.</td></tr>
+<tr>
+<td>port</td><td>The port on which the broker accepts requests.</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_JoinGroup">JoinGroup API (Key: 11):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>JoinGroup Request (Version: 0) => group_id session_timeout member_id protocol_type [group_protocols]
+ group_id => STRING
+ session_timeout => INT32
+ member_id => STRING
+ protocol_type => STRING
+ group_protocols => protocol_name protocol_metadata
+ protocol_name => STRING
+ protocol_metadata => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>session_timeout</td><td>The coordinator considers the consumer dead if it receives no heartbeat after this timeout in ms.</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>protocol_type</td><td>Unique name for class of protocols implemented by group</td></tr>
+<tr>
+<td>group_protocols</td><td>List of protocols that the member supports</td></tr>
+<tr>
+<td>protocol_name</td><td>null</td></tr>
+<tr>
+<td>protocol_metadata</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>JoinGroup Request (Version: 1) => group_id session_timeout rebalance_timeout member_id protocol_type [group_protocols]
+ group_id => STRING
+ session_timeout => INT32
+ rebalance_timeout => INT32
+ member_id => STRING
+ protocol_type => STRING
+ group_protocols => protocol_name protocol_metadata
+ protocol_name => STRING
+ protocol_metadata => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>session_timeout</td><td>The coordinator considers the consumer dead if it receives no heartbeat after this timeout in ms.</td></tr>
+<tr>
+<td>rebalance_timeout</td><td>The maximum time that the coordinator will wait for each member to rejoin when rebalancing the group</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>protocol_type</td><td>Unique name for class of protocols implemented by group</td></tr>
+<tr>
+<td>group_protocols</td><td>List of protocols that the member supports</td></tr>
+<tr>
+<td>protocol_name</td><td>null</td></tr>
+<tr>
+<td>protocol_metadata</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>JoinGroup Request (Version: 2) => group_id session_timeout rebalance_timeout member_id protocol_type [group_protocols]
+ group_id => STRING
+ session_timeout => INT32
+ rebalance_timeout => INT32
+ member_id => STRING
+ protocol_type => STRING
+ group_protocols => protocol_name protocol_metadata
+ protocol_name => STRING
+ protocol_metadata => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>session_timeout</td><td>The coordinator considers the consumer dead if it receives no heartbeat after this timeout in ms.</td></tr>
+<tr>
+<td>rebalance_timeout</td><td>The maximum time that the coordinator will wait for each member to rejoin when rebalancing the group</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>protocol_type</td><td>Unique name for class of protocols implemented by group</td></tr>
+<tr>
+<td>group_protocols</td><td>List of protocols that the member supports</td></tr>
+<tr>
+<td>protocol_name</td><td>null</td></tr>
+<tr>
+<td>protocol_metadata</td><td>null</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>JoinGroup Response (Version: 0) => error_code generation_id group_protocol leader_id member_id [members]
+ error_code => INT16
+ generation_id => INT32
+ group_protocol => STRING
+ leader_id => STRING
+ member_id => STRING
+ members => member_id member_metadata
+ member_id => STRING
+ member_metadata => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>group_protocol</td><td>The group protocol selected by the coordinator</td></tr>
+<tr>
+<td>leader_id</td><td>The leader of the group</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>members</td><td>null</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>member_metadata</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>JoinGroup Response (Version: 1) => error_code generation_id group_protocol leader_id member_id [members]
+ error_code => INT16
+ generation_id => INT32
+ group_protocol => STRING
+ leader_id => STRING
+ member_id => STRING
+ members => member_id member_metadata
+ member_id => STRING
+ member_metadata => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>group_protocol</td><td>The group protocol selected by the coordinator</td></tr>
+<tr>
+<td>leader_id</td><td>The leader of the group</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>members</td><td>null</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>member_metadata</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>JoinGroup Response (Version: 2) => throttle_time_ms error_code generation_id group_protocol leader_id member_id [members]
+ throttle_time_ms => INT32
+ error_code => INT16
+ generation_id => INT32
+ group_protocol => STRING
+ leader_id => STRING
+ member_id => STRING
+ members => member_id member_metadata
+ member_id => STRING
+ member_metadata => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>group_protocol</td><td>The group protocol selected by the coordinator</td></tr>
+<tr>
+<td>leader_id</td><td>The leader of the group</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>members</td><td>null</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>member_metadata</td><td>null</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_Heartbeat">Heartbeat API (Key: 12):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>Heartbeat Request (Version: 0) => group_id generation_id member_id
+ group_id => STRING
+ generation_id => INT32
+ member_id => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+</table>
+</p>
+<p><pre>Heartbeat Request (Version: 1) => group_id generation_id member_id
+ group_id => STRING
+ generation_id => INT32
+ member_id => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>Heartbeat Response (Version: 0) => error_code
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>Heartbeat Response (Version: 1) => throttle_time_ms error_code
+ throttle_time_ms => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_LeaveGroup">LeaveGroup API (Key: 13):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>LeaveGroup Request (Version: 0) => group_id member_id
+ group_id => STRING
+ member_id => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+</table>
+</p>
+<p><pre>LeaveGroup Request (Version: 1) => group_id member_id
+ group_id => STRING
+ member_id => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>LeaveGroup Response (Version: 0) => error_code
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>LeaveGroup Response (Version: 1) => throttle_time_ms error_code
+ throttle_time_ms => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_SyncGroup">SyncGroup API (Key: 14):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>SyncGroup Request (Version: 0) => group_id generation_id member_id [group_assignment]
+ group_id => STRING
+ generation_id => INT32
+ member_id => STRING
+ group_assignment => member_id member_assignment
+ member_id => STRING
+ member_assignment => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>group_assignment</td><td>null</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>member_assignment</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>SyncGroup Request (Version: 1) => group_id generation_id member_id [group_assignment]
+ group_id => STRING
+ generation_id => INT32
+ member_id => STRING
+ group_assignment => member_id member_assignment
+ member_id => STRING
+ member_assignment => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>generation_id</td><td>The generation of the group.</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>group_assignment</td><td>null</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>member_assignment</td><td>null</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>SyncGroup Response (Version: 0) => error_code member_assignment
+ error_code => INT16
+ member_assignment => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>member_assignment</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>SyncGroup Response (Version: 1) => throttle_time_ms error_code member_assignment
+ throttle_time_ms => INT32
+ error_code => INT16
+ member_assignment => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>member_assignment</td><td>null</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DescribeGroups">DescribeGroups API (Key: 15):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DescribeGroups Request (Version: 0) => [group_ids]
+ group_ids => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_ids</td><td>List of groupIds to request metadata for (an empty groupId array will return empty group metadata).</td></tr>
+</table>
+</p>
+<p><pre>DescribeGroups Request (Version: 1) => [group_ids]
+ group_ids => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>group_ids</td><td>List of groupIds to request metadata for (an empty groupId array will return empty group metadata).</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DescribeGroups Response (Version: 0) => [groups]
+ groups => error_code group_id state protocol_type protocol [members]
+ error_code => INT16
+ group_id => STRING
+ state => STRING
+ protocol_type => STRING
+ protocol => STRING
+ members => member_id client_id client_host member_metadata member_assignment
+ member_id => STRING
+ client_id => STRING
+ client_host => STRING
+ member_metadata => BYTES
+ member_assignment => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>groups</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>state</td><td>The current state of the group (one of: Dead, Stable, CompletingRebalance, PreparingRebalance, or empty if there is no active group)</td></tr>
+<tr>
+<td>protocol_type</td><td>The current group protocol type (will be empty if there is no active group)</td></tr>
+<tr>
+<td>protocol</td><td>The current group protocol (only provided if the group is Stable)</td></tr>
+<tr>
+<td>members</td><td>Current group members (only provided if the group is not Dead)</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>client_id</td><td>The client id used in the member's latest join group request</td></tr>
+<tr>
+<td>client_host</td><td>The client host used in the request session corresponding to the member's join group.</td></tr>
+<tr>
+<td>member_metadata</td><td>The metadata corresponding to the current group protocol in use (will only be present if the group is stable).</td></tr>
+<tr>
+<td>member_assignment</td><td>The current assignment provided by the group leader (will only be present if the group is stable).</td></tr>
+</table>
+</p>
+<p><pre>DescribeGroups Response (Version: 1) => throttle_time_ms [groups]
+ throttle_time_ms => INT32
+ groups => error_code group_id state protocol_type protocol [members]
+ error_code => INT16
+ group_id => STRING
+ state => STRING
+ protocol_type => STRING
+ protocol => STRING
+ members => member_id client_id client_host member_metadata member_assignment
+ member_id => STRING
+ client_id => STRING
+ client_host => STRING
+ member_metadata => BYTES
+ member_assignment => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>groups</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>state</td><td>The current state of the group (one of: Dead, Stable, CompletingRebalance, PreparingRebalance, or empty if there is no active group)</td></tr>
+<tr>
+<td>protocol_type</td><td>The current group protocol type (will be empty if there is no active group)</td></tr>
+<tr>
+<td>protocol</td><td>The current group protocol (only provided if the group is Stable)</td></tr>
+<tr>
+<td>members</td><td>Current group members (only provided if the group is not Dead)</td></tr>
+<tr>
+<td>member_id</td><td>The member id assigned by the group coordinator or null if joining for the first time.</td></tr>
+<tr>
+<td>client_id</td><td>The client id used in the member's latest join group request</td></tr>
+<tr>
+<td>client_host</td><td>The client host used in the request session corresponding to the member's join group.</td></tr>
+<tr>
+<td>member_metadata</td><td>The metadata corresponding to the current group protocol in use (will only be present if the group is stable).</td></tr>
+<tr>
+<td>member_assignment</td><td>The current assignment provided by the group leader (will only be present if the group is stable).</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_ListGroups">ListGroups API (Key: 16):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>ListGroups Request (Version: 0) =>
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr></table>
+</p>
+<p><pre>ListGroups Request (Version: 1) =>
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr></table>
+</p>
+<b>Responses:</b><br>
+<p><pre>ListGroups Response (Version: 0) => error_code [groups]
+ error_code => INT16
+ groups => group_id protocol_type
+ group_id => STRING
+ protocol_type => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>groups</td><td>null</td></tr>
+<tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>protocol_type</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>ListGroups Response (Version: 1) => throttle_time_ms error_code [groups]
+ throttle_time_ms => INT32
+ error_code => INT16
+ groups => group_id protocol_type
+ group_id => STRING
+ protocol_type => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>groups</td><td>null</td></tr>
+<tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>protocol_type</td><td>null</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_SaslHandshake">SaslHandshake API (Key: 17):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>SaslHandshake Request (Version: 0) => mechanism
+ mechanism => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>mechanism</td><td>SASL Mechanism chosen by the client.</td></tr>
+</table>
+</p>
+<p><pre>SaslHandshake Request (Version: 1) => mechanism
+ mechanism => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>mechanism</td><td>SASL Mechanism chosen by the client.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>SaslHandshake Response (Version: 0) => error_code [enabled_mechanisms]
+ error_code => INT16
+ enabled_mechanisms => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>enabled_mechanisms</td><td>Array of mechanisms enabled in the server.</td></tr>
+</table>
+</p>
+<p><pre>SaslHandshake Response (Version: 1) => error_code [enabled_mechanisms]
+ error_code => INT16
+ enabled_mechanisms => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>enabled_mechanisms</td><td>Array of mechanisms enabled in the server.</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_ApiVersions">ApiVersions API (Key: 18):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>ApiVersions Request (Version: 0) =>
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr></table>
+</p>
+<p><pre>ApiVersions Request (Version: 1) =>
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr></table>
+</p>
+<b>Responses:</b><br>
+<p><pre>ApiVersions Response (Version: 0) => error_code [api_versions]
+ error_code => INT16
+ api_versions => api_key min_version max_version
+ api_key => INT16
+ min_version => INT16
+ max_version => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>api_versions</td><td>API versions supported by the broker.</td></tr>
+<tr>
+<td>api_key</td><td>API key.</td></tr>
+<tr>
+<td>min_version</td><td>Minimum supported version.</td></tr>
+<tr>
+<td>max_version</td><td>Maximum supported version.</td></tr>
+</table>
+</p>
+<p><pre>ApiVersions Response (Version: 1) => error_code [api_versions] throttle_time_ms
+ error_code => INT16
+ api_versions => api_key min_version max_version
+ api_key => INT16
+ min_version => INT16
+ max_version => INT16
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>api_versions</td><td>API versions supported by the broker.</td></tr>
+<tr>
+<td>api_key</td><td>API key.</td></tr>
+<tr>
+<td>min_version</td><td>Minimum supported version.</td></tr>
+<tr>
+<td>max_version</td><td>Maximum supported version.</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_CreateTopics">CreateTopics API (Key: 19):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>CreateTopics Request (Version: 0) => [create_topic_requests] timeout
+ create_topic_requests => topic num_partitions replication_factor [replica_assignment] [config_entries]
+ topic => STRING
+ num_partitions => INT32
+ replication_factor => INT16
+ replica_assignment => partition [replicas]
+ partition => INT32
+ replicas => INT32
+ config_entries => config_name config_value
+ config_name => STRING
+ config_value => NULLABLE_STRING
+ timeout => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>create_topic_requests</td><td>An array of single topic creation requests. Can not have multiple entries for the same topic.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>num_partitions</td><td>Number of partitions to be created. -1 indicates unset.</td></tr>
+<tr>
+<td>replication_factor</td><td>Replication factor for the topic. -1 indicates unset.</td></tr>
+<tr>
+<td>replica_assignment</td><td>Replica assignment among kafka brokers for this topic partitions. If this is set num_partitions and replication_factor must be unset.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that should host this partition. The first replica in the list is the preferred leader.</td></tr>
+<tr>
+<td>config_entries</td><td>Topic level configuration for topic to be set.</td></tr>
+<tr>
+<td>config_name</td><td>Configuration name</td></tr>
+<tr>
+<td>config_value</td><td>Configuration value</td></tr>
+<tr>
+<td>timeout</td><td>The time in ms to wait for a topic to be completely created on the controller node. Values <= 0 will trigger topic creation and return immediately</td></tr>
+</table>
+</p>
+<p><pre>CreateTopics Request (Version: 1) => [create_topic_requests] timeout validate_only
+ create_topic_requests => topic num_partitions replication_factor [replica_assignment] [config_entries]
+ topic => STRING
+ num_partitions => INT32
+ replication_factor => INT16
+ replica_assignment => partition [replicas]
+ partition => INT32
+ replicas => INT32
+ config_entries => config_name config_value
+ config_name => STRING
+ config_value => NULLABLE_STRING
+ timeout => INT32
+ validate_only => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>create_topic_requests</td><td>An array of single topic creation requests. Can not have multiple entries for the same topic.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>num_partitions</td><td>Number of partitions to be created. -1 indicates unset.</td></tr>
+<tr>
+<td>replication_factor</td><td>Replication factor for the topic. -1 indicates unset.</td></tr>
+<tr>
+<td>replica_assignment</td><td>Replica assignment among kafka brokers for this topic partitions. If this is set num_partitions and replication_factor must be unset.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that should host this partition. The first replica in the list is the preferred leader.</td></tr>
+<tr>
+<td>config_entries</td><td>Topic level configuration for topic to be set.</td></tr>
+<tr>
+<td>config_name</td><td>Configuration name</td></tr>
+<tr>
+<td>config_value</td><td>Configuration value</td></tr>
+<tr>
+<td>timeout</td><td>The time in ms to wait for a topic to be completely created on the controller node. Values <= 0 will trigger topic creation and return immediately</td></tr>
+<tr>
+<td>validate_only</td><td>If this is true, the request will be validated, but the topic won't be created.</td></tr>
+</table>
+</p>
+<p><pre>CreateTopics Request (Version: 2) => [create_topic_requests] timeout validate_only
+ create_topic_requests => topic num_partitions replication_factor [replica_assignment] [config_entries]
+ topic => STRING
+ num_partitions => INT32
+ replication_factor => INT16
+ replica_assignment => partition [replicas]
+ partition => INT32
+ replicas => INT32
+ config_entries => config_name config_value
+ config_name => STRING
+ config_value => NULLABLE_STRING
+ timeout => INT32
+ validate_only => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>create_topic_requests</td><td>An array of single topic creation requests. Can not have multiple entries for the same topic.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>num_partitions</td><td>Number of partitions to be created. -1 indicates unset.</td></tr>
+<tr>
+<td>replication_factor</td><td>Replication factor for the topic. -1 indicates unset.</td></tr>
+<tr>
+<td>replica_assignment</td><td>Replica assignment among kafka brokers for this topic partitions. If this is set num_partitions and replication_factor must be unset.</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>replicas</td><td>The set of all nodes that should host this partition. The first replica in the list is the preferred leader.</td></tr>
+<tr>
+<td>config_entries</td><td>Topic level configuration for topic to be set.</td></tr>
+<tr>
+<td>config_name</td><td>Configuration name</td></tr>
+<tr>
+<td>config_value</td><td>Configuration value</td></tr>
+<tr>
+<td>timeout</td><td>The time in ms to wait for a topic to be completely created on the controller node. Values <= 0 will trigger topic creation and return immediately</td></tr>
+<tr>
+<td>validate_only</td><td>If this is true, the request will be validated, but the topic won't be created.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>CreateTopics Response (Version: 0) => [topic_errors]
+ topic_errors => topic error_code
+ topic => STRING
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topic_errors</td><td>An array of per topic error codes.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>CreateTopics Response (Version: 1) => [topic_errors]
+ topic_errors => topic error_code error_message
+ topic => STRING
+ error_code => INT16
+ error_message => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topic_errors</td><td>An array of per topic errors.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+</table>
+</p>
+<p><pre>CreateTopics Response (Version: 2) => throttle_time_ms [topic_errors]
+ throttle_time_ms => INT32
+ topic_errors => topic error_code error_message
+ topic => STRING
+ error_code => INT16
+ error_message => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>topic_errors</td><td>An array of per topic errors.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DeleteTopics">DeleteTopics API (Key: 20):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DeleteTopics Request (Version: 0) => [topics] timeout
+ topics => STRING
+ timeout => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to be deleted.</td></tr>
+<tr>
+<td>timeout</td><td>The time in ms to wait for a topic to be completely deleted on the controller node. Values <= 0 will trigger topic deletion and return immediately</td></tr>
+</table>
+</p>
+<p><pre>DeleteTopics Request (Version: 1) => [topics] timeout
+ topics => STRING
+ timeout => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to be deleted.</td></tr>
+<tr>
+<td>timeout</td><td>The time in ms to wait for a topic to be completely deleted on the controller node. Values <= 0 will trigger topic deletion and return immediately</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DeleteTopics Response (Version: 0) => [topic_error_codes]
+ topic_error_codes => topic error_code
+ topic => STRING
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topic_error_codes</td><td>An array of per topic error codes.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<p><pre>DeleteTopics Response (Version: 1) => throttle_time_ms [topic_error_codes]
+ throttle_time_ms => INT32
+ topic_error_codes => topic error_code
+ topic => STRING
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>topic_error_codes</td><td>An array of per topic error codes.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DeleteRecords">DeleteRecords API (Key: 21):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DeleteRecords Request (Version: 0) => [topics] timeout
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition offset
+ partition => INT32
+ offset => INT64
+ timeout => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>The offset before which the messages will be deleted. -1 means high-watermark for the partition.</td></tr>
+<tr>
+<td>timeout</td><td>The maximum time to await a response in ms.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DeleteRecords Response (Version: 0) => throttle_time_ms [topics]
+ throttle_time_ms => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition low_watermark error_code
+ partition => INT32
+ low_watermark => INT64
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>topics</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>low_watermark</td><td>Smallest available offset of all live replicas</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_InitProducerId">InitProducerId API (Key: 22):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>InitProducerId Request (Version: 0) => transactional_id transaction_timeout_ms
+ transactional_id => NULLABLE_STRING
+ transaction_timeout_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transactional_id</td><td>The transactional id or null if the producer is not transactional</td></tr>
+<tr>
+<td>transaction_timeout_ms</td><td>The time in ms to wait for before aborting idle transactions sent by this producer.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>InitProducerId Response (Version: 0) => throttle_time_ms error_code producer_id producer_epoch
+ throttle_time_ms => INT32
+ error_code => INT16
+ producer_id => INT64
+ producer_epoch => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>producer_id</td><td>Current producer id in use by the transactional id.</td></tr>
+<tr>
+<td>producer_epoch</td><td>Current epoch associated with the producer id.</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_OffsetForLeaderEpoch">OffsetForLeaderEpoch API (Key: 23):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>OffsetForLeaderEpoch Request (Version: 0) => [topics]
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition leader_epoch
+ partition => INT32
+ leader_epoch => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics to get epochs for</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>leader_epoch</td><td>The epoch</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>OffsetForLeaderEpoch Response (Version: 0) => [topics]
+ topics => topic [partitions]
+ topic => STRING
+ partitions => error_code partition end_offset
+ error_code => INT16
+ partition => INT32
+ end_offset => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>An array of topics for which we have leader offsets for some requested Partition Leader Epoch</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>end_offset</td><td>The end offset</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_AddPartitionsToTxn">AddPartitionsToTxn API (Key: 24):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>AddPartitionsToTxn Request (Version: 0) => transactional_id producer_id producer_epoch [topics]
+ transactional_id => STRING
+ producer_id => INT64
+ producer_epoch => INT16
+ topics => topic [partitions]
+ topic => STRING
+ partitions => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transactional_id</td><td>The transactional id corresponding to the transaction.</td></tr>
+<tr>
+<td>producer_id</td><td>Current producer id in use by the transactional id.</td></tr>
+<tr>
+<td>producer_epoch</td><td>Current epoch associated with the producer id.</td></tr>
+<tr>
+<td>topics</td><td>The partitions to add to the transaction.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>AddPartitionsToTxn Response (Version: 0) => throttle_time_ms [errors]
+ throttle_time_ms => INT32
+ errors => topic [partition_errors]
+ topic => STRING
+ partition_errors => partition error_code
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>errors</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partition_errors</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_AddOffsetsToTxn">AddOffsetsToTxn API (Key: 25):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>AddOffsetsToTxn Request (Version: 0) => transactional_id producer_id producer_epoch group_id
+ transactional_id => STRING
+ producer_id => INT64
+ producer_epoch => INT16
+ group_id => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transactional_id</td><td>The transactional id corresponding to the transaction.</td></tr>
+<tr>
+<td>producer_id</td><td>Current producer id in use by the transactional id.</td></tr>
+<tr>
+<td>producer_epoch</td><td>Current epoch associated with the producer id.</td></tr>
+<tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>AddOffsetsToTxn Response (Version: 0) => throttle_time_ms error_code
+ throttle_time_ms => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_EndTxn">EndTxn API (Key: 26):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>EndTxn Request (Version: 0) => transactional_id producer_id producer_epoch transaction_result
+ transactional_id => STRING
+ producer_id => INT64
+ producer_epoch => INT16
+ transaction_result => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transactional_id</td><td>The transactional id corresponding to the transaction.</td></tr>
+<tr>
+<td>producer_id</td><td>Current producer id in use by the transactional id.</td></tr>
+<tr>
+<td>producer_epoch</td><td>Current epoch associated with the producer id.</td></tr>
+<tr>
+<td>transaction_result</td><td>The result of the transaction (0 = ABORT, 1 = COMMIT)</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>EndTxn Response (Version: 0) => throttle_time_ms error_code
+ throttle_time_ms => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_WriteTxnMarkers">WriteTxnMarkers API (Key: 27):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>WriteTxnMarkers Request (Version: 0) => [transaction_markers]
+ transaction_markers => producer_id producer_epoch transaction_result [topics] coordinator_epoch
+ producer_id => INT64
+ producer_epoch => INT16
+ transaction_result => BOOLEAN
+ topics => topic [partitions]
+ topic => STRING
+ partitions => INT32
+ coordinator_epoch => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transaction_markers</td><td>The transaction markers to be written.</td></tr>
+<tr>
+<td>producer_id</td><td>Current producer id in use by the transactional id.</td></tr>
+<tr>
+<td>producer_epoch</td><td>Current epoch associated with the producer id.</td></tr>
+<tr>
+<td>transaction_result</td><td>The result of the transaction to write to the partitions (false = ABORT, true = COMMIT).</td></tr>
+<tr>
+<td>topics</td><td>The partitions to write markers for.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>coordinator_epoch</td><td>Epoch associated with the transaction state partition hosted by this transaction coordinator</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>WriteTxnMarkers Response (Version: 0) => [transaction_markers]
+ transaction_markers => producer_id [topics]
+ producer_id => INT64
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition error_code
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transaction_markers</td><td>Errors per partition from writing markers.</td></tr>
+<tr>
+<td>producer_id</td><td>Current producer id in use by the transactional id.</td></tr>
+<tr>
+<td>topics</td><td>Errors per partition from writing markers.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_TxnOffsetCommit">TxnOffsetCommit API (Key: 28):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>TxnOffsetCommit Request (Version: 0) => transactional_id group_id producer_id producer_epoch [topics]
+ transactional_id => STRING
+ group_id => STRING
+ producer_id => INT64
+ producer_epoch => INT16
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition offset metadata
+ partition => INT32
+ offset => INT64
+ metadata => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>transactional_id</td><td>The transactional id corresponding to the transaction.</td></tr>
+<tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>producer_id</td><td>Current producer id in use by the transactional id.</td></tr>
+<tr>
+<td>producer_epoch</td><td>Current epoch associated with the producer id.</td></tr>
+<tr>
+<td>topics</td><td>The partitions to write markers for.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>offset</td><td>null</td></tr>
+<tr>
+<td>metadata</td><td>null</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>TxnOffsetCommit Response (Version: 0) => throttle_time_ms [topics]
+ throttle_time_ms => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition error_code
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>topics</td><td>Errors per partition from writing markers.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DescribeAcls">DescribeAcls API (Key: 29):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DescribeAcls Request (Version: 0) => resource_type resource_name principal host operation permission_type
+ resource_type => INT8
+ resource_name => NULLABLE_STRING
+ principal => NULLABLE_STRING
+ host => NULLABLE_STRING
+ operation => INT8
+ permission_type => INT8
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>resource_type</td><td>The resource type</td></tr>
+<tr>
+<td>resource_name</td><td>The resource name filter</td></tr>
+<tr>
+<td>principal</td><td>The ACL principal filter</td></tr>
+<tr>
+<td>host</td><td>The ACL host filter</td></tr>
+<tr>
+<td>operation</td><td>The ACL operation</td></tr>
+<tr>
+<td>permission_type</td><td>The ACL permission type</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DescribeAcls Response (Version: 0) => throttle_time_ms error_code error_message [resources]
+ throttle_time_ms => INT32
+ error_code => INT16
+ error_message => NULLABLE_STRING
+ resources => resource_type resource_name [acls]
+ resource_type => INT8
+ resource_name => STRING
+ acls => principal host operation permission_type
+ principal => STRING
+ host => STRING
+ operation => INT8
+ permission_type => INT8
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+<tr>
+<td>resources</td><td>The resources and their associated ACLs.</td></tr>
+<tr>
+<td>resource_type</td><td>The resource type</td></tr>
+<tr>
+<td>resource_name</td><td>The resource name</td></tr>
+<tr>
+<td>acls</td><td>null</td></tr>
+<tr>
+<td>principal</td><td>The ACL principal</td></tr>
+<tr>
+<td>host</td><td>The ACL host</td></tr>
+<tr>
+<td>operation</td><td>The ACL operation</td></tr>
+<tr>
+<td>permission_type</td><td>The ACL permission type</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_CreateAcls">CreateAcls API (Key: 30):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>CreateAcls Request (Version: 0) => [creations]
+ creations => resource_type resource_name principal host operation permission_type
+ resource_type => INT8
+ resource_name => STRING
+ principal => STRING
+ host => STRING
+ operation => INT8
+ permission_type => INT8
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>creations</td><td>null</td></tr>
+<tr>
+<td>resource_type</td><td>The resource type</td></tr>
+<tr>
+<td>resource_name</td><td>The resource name</td></tr>
+<tr>
+<td>principal</td><td>The ACL principal</td></tr>
+<tr>
+<td>host</td><td>The ACL host</td></tr>
+<tr>
+<td>operation</td><td>The ACL operation</td></tr>
+<tr>
+<td>permission_type</td><td>The ACL permission type</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>CreateAcls Response (Version: 0) => throttle_time_ms [creation_responses]
+ throttle_time_ms => INT32
+ creation_responses => error_code error_message
+ error_code => INT16
+ error_message => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>creation_responses</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DeleteAcls">DeleteAcls API (Key: 31):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DeleteAcls Request (Version: 0) => [filters]
+ filters => resource_type resource_name principal host operation permission_type
+ resource_type => INT8
+ resource_name => NULLABLE_STRING
+ principal => NULLABLE_STRING
+ host => NULLABLE_STRING
+ operation => INT8
+ permission_type => INT8
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>filters</td><td>null</td></tr>
+<tr>
+<td>resource_type</td><td>The resource type</td></tr>
+<tr>
+<td>resource_name</td><td>The resource name filter</td></tr>
+<tr>
+<td>principal</td><td>The ACL principal filter</td></tr>
+<tr>
+<td>host</td><td>The ACL host filter</td></tr>
+<tr>
+<td>operation</td><td>The ACL operation</td></tr>
+<tr>
+<td>permission_type</td><td>The ACL permission type</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DeleteAcls Response (Version: 0) => throttle_time_ms [filter_responses]
+ throttle_time_ms => INT32
+ filter_responses => error_code error_message [matching_acls]
+ error_code => INT16
+ error_message => NULLABLE_STRING
+ matching_acls => error_code error_message resource_type resource_name principal host operation permission_type
+ error_code => INT16
+ error_message => NULLABLE_STRING
+ resource_type => INT8
+ resource_name => STRING
+ principal => STRING
+ host => STRING
+ operation => INT8
+ permission_type => INT8
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>filter_responses</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+<tr>
+<td>matching_acls</td><td>The matching ACLs</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+<tr>
+<td>resource_type</td><td>The resource type</td></tr>
+<tr>
+<td>resource_name</td><td>The resource name</td></tr>
+<tr>
+<td>principal</td><td>The ACL principal</td></tr>
+<tr>
+<td>host</td><td>The ACL host</td></tr>
+<tr>
+<td>operation</td><td>The ACL operation</td></tr>
+<tr>
+<td>permission_type</td><td>The ACL permission type</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DescribeConfigs">DescribeConfigs API (Key: 32):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DescribeConfigs Request (Version: 0) => [resources]
+ resources => resource_type resource_name [config_names]
+ resource_type => INT8
+ resource_name => STRING
+ config_names => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>resources</td><td>An array of config resources to be returned.</td></tr>
+<tr>
+<td>resource_type</td><td>null</td></tr>
+<tr>
+<td>resource_name</td><td>null</td></tr>
+<tr>
+<td>config_names</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>DescribeConfigs Request (Version: 1) => [resources] include_synonyms
+ resources => resource_type resource_name [config_names]
+ resource_type => INT8
+ resource_name => STRING
+ config_names => STRING
+ include_synonyms => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>resources</td><td>An array of config resources to be returned.</td></tr>
+<tr>
+<td>resource_type</td><td>null</td></tr>
+<tr>
+<td>resource_name</td><td>null</td></tr>
+<tr>
+<td>config_names</td><td>null</td></tr>
+<tr>
+<td>include_synonyms</td><td>null</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DescribeConfigs Response (Version: 0) => throttle_time_ms [resources]
+ throttle_time_ms => INT32
+ resources => error_code error_message resource_type resource_name [config_entries]
+ error_code => INT16
+ error_message => NULLABLE_STRING
+ resource_type => INT8
+ resource_name => STRING
+ config_entries => config_name config_value read_only is_default is_sensitive
+ config_name => STRING
+ config_value => NULLABLE_STRING
+ read_only => BOOLEAN
+ is_default => BOOLEAN
+ is_sensitive => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>resources</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+<tr>
+<td>resource_type</td><td>null</td></tr>
+<tr>
+<td>resource_name</td><td>null</td></tr>
+<tr>
+<td>config_entries</td><td>null</td></tr>
+<tr>
+<td>config_name</td><td>null</td></tr>
+<tr>
+<td>config_value</td><td>null</td></tr>
+<tr>
+<td>read_only</td><td>null</td></tr>
+<tr>
+<td>is_default</td><td>null</td></tr>
+<tr>
+<td>is_sensitive</td><td>null</td></tr>
+</table>
+</p>
+<p><pre>DescribeConfigs Response (Version: 1) => throttle_time_ms [resources]
+ throttle_time_ms => INT32
+ resources => error_code error_message resource_type resource_name [config_entries]
+ error_code => INT16
+ error_message => NULLABLE_STRING
+ resource_type => INT8
+ resource_name => STRING
+ config_entries => config_name config_value read_only config_source is_sensitive [config_synonyms]
+ config_name => STRING
+ config_value => NULLABLE_STRING
+ read_only => BOOLEAN
+ config_source => INT8
+ is_sensitive => BOOLEAN
+ config_synonyms => config_name config_value config_source
+ config_name => STRING
+ config_value => NULLABLE_STRING
+ config_source => INT8
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>resources</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+<tr>
+<td>resource_type</td><td>null</td></tr>
+<tr>
+<td>resource_name</td><td>null</td></tr>
+<tr>
+<td>config_entries</td><td>null</td></tr>
+<tr>
+<td>config_name</td><td>null</td></tr>
+<tr>
+<td>config_value</td><td>null</td></tr>
+<tr>
+<td>read_only</td><td>null</td></tr>
+<tr>
+<td>config_source</td><td>null</td></tr>
+<tr>
+<td>is_sensitive</td><td>null</td></tr>
+<tr>
+<td>config_synonyms</td><td>null</td></tr>
+<tr>
+<td>config_name</td><td>null</td></tr>
+<tr>
+<td>config_value</td><td>null</td></tr>
+<tr>
+<td>config_source</td><td>null</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_AlterConfigs">AlterConfigs API (Key: 33):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>AlterConfigs Request (Version: 0) => [resources] validate_only
+ resources => resource_type resource_name [config_entries]
+ resource_type => INT8
+ resource_name => STRING
+ config_entries => config_name config_value
+ config_name => STRING
+ config_value => NULLABLE_STRING
+ validate_only => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>resources</td><td>An array of resources to update with the provided configs.</td></tr>
+<tr>
+<td>resource_type</td><td>null</td></tr>
+<tr>
+<td>resource_name</td><td>null</td></tr>
+<tr>
+<td>config_entries</td><td>null</td></tr>
+<tr>
+<td>config_name</td><td>Configuration name</td></tr>
+<tr>
+<td>config_value</td><td>Configuration value</td></tr>
+<tr>
+<td>validate_only</td><td>null</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>AlterConfigs Response (Version: 0) => throttle_time_ms [resources]
+ throttle_time_ms => INT32
+ resources => error_code error_message resource_type resource_name
+ error_code => INT16
+ error_message => NULLABLE_STRING
+ resource_type => INT8
+ resource_name => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>resources</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+<tr>
+<td>resource_type</td><td>null</td></tr>
+<tr>
+<td>resource_name</td><td>null</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_AlterReplicaLogDirs">AlterReplicaLogDirs API (Key: 34):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>AlterReplicaLogDirs Request (Version: 0) => [log_dirs]
+ log_dirs => log_dir [topics]
+ log_dir => STRING
+ topics => topic [partitions]
+ topic => STRING
+ partitions => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>log_dirs</td><td>null</td></tr>
+<tr>
+<td>log_dir</td><td>The absolute log directory path.</td></tr>
+<tr>
+<td>topics</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>List of partition ids of the topic.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>AlterReplicaLogDirs Response (Version: 0) => throttle_time_ms [topics]
+ throttle_time_ms => INT32
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition error_code
+ partition => INT32
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>topics</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DescribeLogDirs">DescribeLogDirs API (Key: 35):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DescribeLogDirs Request (Version: 0) => [topics]
+ topics => topic [partitions]
+ topic => STRING
+ partitions => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topics</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>List of partition ids of the topic.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DescribeLogDirs Response (Version: 0) => throttle_time_ms [log_dirs]
+ throttle_time_ms => INT32
+ log_dirs => error_code log_dir [topics]
+ error_code => INT16
+ log_dir => STRING
+ topics => topic [partitions]
+ topic => STRING
+ partitions => partition size offset_lag is_future
+ partition => INT32
+ size => INT64
+ offset_lag => INT64
+ is_future => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>log_dirs</td><td>null</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>log_dir</td><td>The absolute log directory path.</td></tr>
+<tr>
+<td>topics</td><td>null</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>partitions</td><td>null</td></tr>
+<tr>
+<td>partition</td><td>Topic partition id</td></tr>
+<tr>
+<td>size</td><td>The size of the log segments of the partition in bytes.</td></tr>
+<tr>
+<td>offset_lag</td><td>The lag of the log's LEO w.r.t. partition's HW (if it is the current log for the partition) or current replica's LEO (if it is the future log for the partition)</td></tr>
+<tr>
+<td>is_future</td><td>True if this log is created by AlterReplicaLogDirsRequest and will replace the current log of the replica in the future.</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_SaslAuthenticate">SaslAuthenticate API (Key: 36):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>SaslAuthenticate Request (Version: 0) => sasl_auth_bytes
+ sasl_auth_bytes => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>sasl_auth_bytes</td><td>SASL authentication bytes from client as defined by the SASL mechanism.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>SaslAuthenticate Response (Version: 0) => error_code error_message sasl_auth_bytes
+ error_code => INT16
+ error_message => NULLABLE_STRING
+ sasl_auth_bytes => BYTES
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+<tr>
+<td>sasl_auth_bytes</td><td>SASL authentication bytes from server as defined by the SASL mechanism.</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_CreatePartitions">CreatePartitions API (Key: 37):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>CreatePartitions Request (Version: 0) => [topic_partitions] timeout validate_only
+ topic_partitions => topic new_partitions
+ topic => STRING
+ new_partitions => count [assignment]
+ count => INT32
+ assignment => ARRAY(INT32)
+ timeout => INT32
+ validate_only => BOOLEAN
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>topic_partitions</td><td>List of topic and the corresponding new partitions.</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>new_partitions</td><td>null</td></tr>
+<tr>
+<td>count</td><td>The new partition count.</td></tr>
+<tr>
+<td>assignment</td><td>The assigned brokers.</td></tr>
+<tr>
+<td>timeout</td><td>The time in ms to wait for the partitions to be created.</td></tr>
+<tr>
+<td>validate_only</td><td>If true then validate the request, but don't actually increase the number of partitions.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>CreatePartitions Response (Version: 0) => throttle_time_ms [topic_errors]
+ throttle_time_ms => INT32
+ topic_errors => topic error_code error_message
+ topic => STRING
+ error_code => INT16
+ error_message => NULLABLE_STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>topic_errors</td><td>Per topic results for the create partitions request</td></tr>
+<tr>
+<td>topic</td><td>Name of topic</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>error_message</td><td>Response error message</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_CreateDelegationToken">CreateDelegationToken API (Key: 38):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>CreateDelegationToken Request (Version: 0) => [renewers] max_life_time
+ renewers => principal_type name
+ principal_type => STRING
+ name => STRING
+ max_life_time => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>renewers</td><td>An array of token renewers. Renewer is an Kafka PrincipalType and name string, who is allowed to renew this token before the max lifetime expires.</td></tr>
+<tr>
+<td>principal_type</td><td>principalType of the Kafka principal</td></tr>
+<tr>
+<td>name</td><td>name of the Kafka principal</td></tr>
+<tr>
+<td>max_life_time</td><td>Max lifetime period for token in milli seconds. if value is -1, then max lifetime will default to a server side config value.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>CreateDelegationToken Response (Version: 0) => error_code owner issue_timestamp expiry_timestamp max_timestamp token_id hmac throttle_time_ms
+ error_code => INT16
+ owner => principal_type name
+ principal_type => STRING
+ name => STRING
+ issue_timestamp => INT64
+ expiry_timestamp => INT64
+ max_timestamp => INT64
+ token_id => STRING
+ hmac => BYTES
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>owner</td><td>token owner.</td></tr>
+<tr>
+<td>principal_type</td><td>principalType of the Kafka principal</td></tr>
+<tr>
+<td>name</td><td>name of the Kafka principal</td></tr>
+<tr>
+<td>issue_timestamp</td><td>timestamp (in msec) when this token was generated.</td></tr>
+<tr>
+<td>expiry_timestamp</td><td>timestamp (in msec) at which this token expires.</td></tr>
+<tr>
+<td>max_timestamp</td><td>max life time of this token.</td></tr>
+<tr>
+<td>token_id</td><td>UUID to ensure uniqueness.</td></tr>
+<tr>
+<td>hmac</td><td>HMAC of the delegation token.</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_RenewDelegationToken">RenewDelegationToken API (Key: 39):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>RenewDelegationToken Request (Version: 0) => hmac renew_time_period
+ hmac => BYTES
+ renew_time_period => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>hmac</td><td>HMAC of the delegation token to be renewed.</td></tr>
+<tr>
+<td>renew_time_period</td><td>Renew time period in milli seconds.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>RenewDelegationToken Response (Version: 0) => error_code expiry_timestamp throttle_time_ms
+ error_code => INT16
+ expiry_timestamp => INT64
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>expiry_timestamp</td><td>timestamp (in msec) at which this token expires..</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_ExpireDelegationToken">ExpireDelegationToken API (Key: 40):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>ExpireDelegationToken Request (Version: 0) => hmac expiry_time_period
+ hmac => BYTES
+ expiry_time_period => INT64
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>hmac</td><td>HMAC of the delegation token to be expired.</td></tr>
+<tr>
+<td>expiry_time_period</td><td>expiry time period in milli seconds.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>ExpireDelegationToken Response (Version: 0) => error_code expiry_timestamp throttle_time_ms
+ error_code => INT16
+ expiry_timestamp => INT64
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>expiry_timestamp</td><td>timestamp (in msec) at which this token expires..</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DescribeDelegationToken">DescribeDelegationToken API (Key: 41):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DescribeDelegationToken Request (Version: 0) => [owners]
+ owners => principal_type name
+ principal_type => STRING
+ name => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>owners</td><td>An array of token owners.</td></tr>
+<tr>
+<td>principal_type</td><td>principalType of the Kafka principal</td></tr>
+<tr>
+<td>name</td><td>name of the Kafka principal</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DescribeDelegationToken Response (Version: 0) => error_code [token_details] throttle_time_ms
+ error_code => INT16
+ token_details => owner issue_timestamp expiry_timestamp max_timestamp token_id hmac [renewers]
+ owner => principal_type name
+ principal_type => STRING
+ name => STRING
+ issue_timestamp => INT64
+ expiry_timestamp => INT64
+ max_timestamp => INT64
+ token_id => STRING
+ hmac => BYTES
+ renewers => principal_type name
+ principal_type => STRING
+ name => STRING
+ throttle_time_ms => INT32
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>error_code</td><td>Response error code</td></tr>
+<tr>
+<td>token_details</td><td>null</td></tr>
+<tr>
+<td>owner</td><td>token owner.</td></tr>
+<tr>
+<td>principal_type</td><td>principalType of the Kafka principal</td></tr>
+<tr>
+<td>name</td><td>name of the Kafka principal</td></tr>
+<tr>
+<td>issue_timestamp</td><td>timestamp (in msec) when this token was generated.</td></tr>
+<tr>
+<td>expiry_timestamp</td><td>timestamp (in msec) at which this token expires.</td></tr>
+<tr>
+<td>max_timestamp</td><td>max life time of this token.</td></tr>
+<tr>
+<td>token_id</td><td>UUID to ensure uniqueness.</td></tr>
+<tr>
+<td>hmac</td><td>HMAC of the delegation token to be expired.</td></tr>
+<tr>
+<td>renewers</td><td>An array of token renewers. Renewer is an Kafka PrincipalType and name string, who is allowed to renew this token before the max lifetime expires.</td></tr>
+<tr>
+<td>principal_type</td><td>principalType of the Kafka principal</td></tr>
+<tr>
+<td>name</td><td>name of the Kafka principal</td></tr>
+<tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+</table>
+</p>
+<h5><a name="The_Messages_DeleteGroups">DeleteGroups API (Key: 42):</a></h5>
+
+<b>Requests:</b><br>
+<p><pre>DeleteGroups Request (Version: 0) => [groups]
+ groups => STRING
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>groups</td><td>An array of groups to be deleted.</td></tr>
+</table>
+</p>
+<b>Responses:</b><br>
+<p><pre>DeleteGroups Response (Version: 0) => throttle_time_ms [group_error_codes]
+ throttle_time_ms => INT32
+ group_error_codes => group_id error_code
+ group_id => STRING
+ error_code => INT16
+</pre><table class="data-table"><tbody>
+<tr><th>Field</th>
+<th>Description</th>
+</tr><tr>
+<td>throttle_time_ms</td><td>Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota)</td></tr>
+<tr>
+<td>group_error_codes</td><td>An array of per group error codes.</td></tr>
+<tr>
+<td>group_id</td><td>The unique group identifier</td></tr>
+<tr>
+<td>error_code</td><td>Response error code</td></tr>
+</table>
+</p>
+
diff --git a/11/generated/streams_config.html b/11/generated/streams_config.html
new file mode 100644
index 0000000..1b56c88
--- /dev/null
+++ b/11/generated/streams_config.html
@@ -0,0 +1,90 @@
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>application.id</td></td><td>An identifier for the stream processing application. Must be unique within the Kafka cluster. It is used as 1) the default client-id prefix, 2) the group-id for membership management, 3) the changelog topic prefix.</td></td><td>string</td></td><td></td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>bootstrap.servers</td></td><td>A list of host/port pairs to use for establishing the initial connection to the Kafka cluster. The client will make use of all servers irrespective of which servers are specified here for bootstrapping—this list only impacts the initial hosts used to discover the full set of servers. This list should be in the form <code>host1:port1,host2:port2,...</code>. Since these servers are just used for the initial connection to discover the full cluster me [...]
+<tr>
+<td>replication.factor</td></td><td>The replication factor for change log topics and repartition topics created by the stream processing application.</td></td><td>int</td></td><td>1</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>state.dir</td></td><td>Directory location for state store.</td></td><td>string</td></td><td>/tmp/kafka-streams</td></td><td></td></td><td>high</td></td></tr>
+<tr>
+<td>cache.max.bytes.buffering</td></td><td>Maximum number of memory bytes to be used for buffering across all threads</td></td><td>long</td></td><td>10485760</td></td><td>[0,...]</td></td><td>medium</td></td></tr>
+<tr>
+<td>client.id</td></td><td>An ID prefix string used for the client IDs of internal consumer, producer and restore-consumer, with pattern '<client.id>-StreamThread-<threadSequenceNumber>-<consumer|producer|restore-consumer>'.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>default.deserialization.exception.handler</td></td><td>Exception handling class that implements the <code>org.apache.kafka.streams.errors.DeserializationExceptionHandler</code> interface.</td></td><td>class</td></td><td>org.apache.kafka.streams.errors.LogAndFailExceptionHandler</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>default.key.serde</td></td><td> Default serializer / deserializer class for key that implements the <code>org.apache.kafka.common.serialization.Serde</code> interface.</td></td><td>class</td></td><td>org.apache.kafka.common.serialization.Serdes$ByteArraySerde</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>default.production.exception.handler</td></td><td>Exception handling class that implements the <code>org.apache.kafka.streams.errors.ProductionExceptionHandler</code> interface.</td></td><td>class</td></td><td>org.apache.kafka.streams.errors.DefaultProductionExceptionHandler</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>default.timestamp.extractor</td></td><td>Default timestamp extractor class that implements the <code>org.apache.kafka.streams.processor.TimestampExtractor</code> interface.</td></td><td>class</td></td><td>org.apache.kafka.streams.processor.FailOnInvalidTimestamp</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>default.value.serde</td></td><td>Default serializer / deserializer class for value that implements the <code>org.apache.kafka.common.serialization.Serde</code> interface.</td></td><td>class</td></td><td>org.apache.kafka.common.serialization.Serdes$ByteArraySerde</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>num.standby.replicas</td></td><td>The number of standby replicas for each task.</td></td><td>int</td></td><td>0</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>num.stream.threads</td></td><td>The number of threads to execute stream processing.</td></td><td>int</td></td><td>1</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>processing.guarantee</td></td><td>The processing guarantee that should be used. Possible values are <code>at_least_once</code> (default) and <code>exactly_once</code>. Note that exactly-once processing requires a cluster of at least three brokers by default what is the recommended setting for production; for development you can change this, by adjusting broker setting `transaction.state.log.replication.factor`.</td></td><td>string</td></td><td>at_least_once</td></td><td>[at_least_onc [...]
+<tr>
+<td>security.protocol</td></td><td>Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.</td></td><td>string</td></td><td>PLAINTEXT</td></td><td></td></td><td>medium</td></td></tr>
+<tr>
+<td>application.server</td></td><td>A host:port pair pointing to an embedded user defined endpoint that can be used for discovering the locations of state stores within a single KafkaStreams application</td></td><td>string</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>buffered.records.per.partition</td></td><td>The maximum number of records to buffer per partition.</td></td><td>int</td></td><td>1000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>commit.interval.ms</td></td><td>The frequency with which to save the position of the processor. (Note, if 'processing.guarantee' is set to 'exactly_once', the default value is 100, otherwise the default value is 30000.</td></td><td>long</td></td><td>30000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>connections.max.idle.ms</td></td><td>Close idle connections after the number of milliseconds specified by this config.</td></td><td>long</td></td><td>540000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>key.serde</td></td><td>Serializer / deserializer class for key that implements the <code>org.apache.kafka.common.serialization.Serde</code> interface. This config is deprecated, use <code>default.key.serde</code> instead</td></td><td>class</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>metadata.max.age.ms</td></td><td>The period of time in milliseconds after which we force a refresh of metadata even if we haven't seen any partition leadership changes to proactively discover any new brokers or partitions.</td></td><td>long</td></td><td>300000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metric.reporters</td></td><td>A list of classes to use as metrics reporters. Implementing the <code>org.apache.kafka.common.metrics.MetricsReporter</code> interface allows plugging in classes that will be notified of new metric creation. The JmxReporter is always included to register JMX statistics.</td></td><td>list</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.num.samples</td></td><td>The number of samples maintained to compute metrics.</td></td><td>int</td></td><td>2</td></td><td>[1,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.recording.level</td></td><td>The highest recording level for metrics.</td></td><td>string</td></td><td>INFO</td></td><td>[INFO, DEBUG]</td></td><td>low</td></td></tr>
+<tr>
+<td>metrics.sample.window.ms</td></td><td>The window of time a metrics sample is computed over.</td></td><td>long</td></td><td>30000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>partition.grouper</td></td><td>Partition grouper class that implements the <code>org.apache.kafka.streams.processor.PartitionGrouper</code> interface.</td></td><td>class</td></td><td>org.apache.kafka.streams.processor.DefaultPartitionGrouper</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>poll.ms</td></td><td>The amount of time in milliseconds to block waiting for input.</td></td><td>long</td></td><td>100</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>receive.buffer.bytes</td></td><td>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>32768</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.max.ms</td></td><td>The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.</td></td><td>long</td></td><td>1000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>reconnect.backoff.ms</td></td><td>The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker.</td></td><td>long</td></td><td>50</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>request.timeout.ms</td></td><td>The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted.</td></td><td>int</td></td><td>40000</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>retries</td></td><td>Setting a value greater than zero will cause the client to resend any request that fails with a potentially transient error.</td></td><td>int</td></td><td>0</td></td><td>[0,...,2147483647]</td></td><td>low</td></td></tr>
+<tr>
+<td>retry.backoff.ms</td></td><td>The amount of time to wait before attempting to retry a failed request to a given topic partition. This avoids repeatedly sending requests in a tight loop under some failure scenarios.</td></td><td>long</td></td><td>100</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>rocksdb.config.setter</td></td><td>A Rocks DB config setter class or class name that implements the <code>org.apache.kafka.streams.state.RocksDBConfigSetter</code> interface</td></td><td>class</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>send.buffer.bytes</td></td><td>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default will be used.</td></td><td>int</td></td><td>131072</td></td><td>[0,...]</td></td><td>low</td></td></tr>
+<tr>
+<td>state.cleanup.delay.ms</td></td><td>The amount of time in milliseconds to wait before deleting state when a partition has migrated. Only state directories that have not been modified for at least state.cleanup.delay.ms will be removed</td></td><td>long</td></td><td>600000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>timestamp.extractor</td></td><td>Timestamp extractor class that implements the <code>org.apache.kafka.streams.processor.TimestampExtractor</code> interface. This config is deprecated, use <code>default.timestamp.extractor</code> instead</td></td><td>class</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>value.serde</td></td><td>Serializer / deserializer class for value that implements the <code>org.apache.kafka.common.serialization.Serde</code> interface. This config is deprecated, use <code>default.value.serde</code> instead</td></td><td>class</td></td><td>null</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>windowstore.changelog.additional.retention.ms</td></td><td>Added to a windows maintainMs to ensure data is not deleted from the log prematurely. Allows for clock drift. Default is 1 day</td></td><td>long</td></td><td>86400000</td></td><td></td></td><td>low</td></td></tr>
+<tr>
+<td>zookeeper.connect</td></td><td>Zookeeper connect string for Kafka topics management. This config is deprecated and will be ignored as Streams API does not use Zookeeper anymore.</td></td><td>string</td></td><td>""</td></td><td></td></td><td>low</td></td></tr>
+</tbody></table>
diff --git a/11/generated/topic_config.html b/11/generated/topic_config.html
new file mode 100644
index 0000000..da7bef9
--- /dev/null
+++ b/11/generated/topic_config.html
@@ -0,0 +1,59 @@
+<table class="data-table"><tbody>
+<tr>
+<th>Name</th>
+<th>Description</th>
+<th>Type</th>
+<th>Default</th>
+<th>Valid Values</th>
+<th>Server Default Property</th>
+<th>Importance</th>
+</tr>
+<tr>
+<td>cleanup.policy</td></td><td>A string that is either "delete" or "compact". This string designates the retention policy to use on old log segments. The default policy ("delete") will discard old segments when their retention time or size limit has been reached. The "compact" setting will enable <a href="#compaction">log compaction</a> on the topic.</td></td><td>list</td></td><td>delete</td></td><td>[compact, delete]</td></td><td>log.cleanup.policy</td></td><td>medium</td></td></tr>
+<tr>
+<td>compression.type</td></td><td>Specify the final compression type for a given topic. This configuration accepts the standard compression codecs ('gzip', 'snappy', lz4). It additionally accepts 'uncompressed' which is equivalent to no compression; and 'producer' which means retain the original compression codec set by the producer.</td></td><td>string</td></td><td>producer</td></td><td>[uncompressed, snappy, lz4, gzip, producer]</td></td><td>compression.type</td></td><td>medium</td></td></tr>
+<tr>
+<td>delete.retention.ms</td></td><td>The amount of time to retain delete tombstone markers for <a href="#compaction">log compacted</a> topics. This setting also gives a bound on the time in which a consumer must complete a read if they begin from offset 0 to ensure that they get a valid snapshot of the final stage (otherwise delete tombstones may be collected before they complete their scan).</td></td><td>long</td></td><td>86400000</td></td><td>[0,...]</td></td><td>log.cleaner.delete.ret [...]
+<tr>
+<td>file.delete.delay.ms</td></td><td>The time to wait before deleting a file from the filesystem</td></td><td>long</td></td><td>60000</td></td><td>[0,...]</td></td><td>log.segment.delete.delay.ms</td></td><td>medium</td></td></tr>
+<tr>
+<td>flush.messages</td></td><td>This setting allows specifying an interval at which we will force an fsync of data written to the log. For example if this was set to 1 we would fsync after every message; if it were 5 we would fsync after every five messages. In general we recommend you not set this and use replication for durability and allow the operating system's background flush capabilities as it is more efficient. This setting can be overridden on a per-topic basis (see <a href="#to [...]
+<tr>
+<td>flush.ms</td></td><td>This setting allows specifying a time interval at which we will force an fsync of data written to the log. For example if this was set to 1000 we would fsync after 1000 ms had passed. In general we recommend you not set this and use replication for durability and allow the operating system's background flush capabilities as it is more efficient.</td></td><td>long</td></td><td>9223372036854775807</td></td><td>[0,...]</td></td><td>log.flush.interval.ms</td></td><t [...]
+<tr>
+<td>follower.replication.throttled.replicas</td></td><td>A list of replicas for which log replication should be throttled on the follower side. The list should describe a set of replicas in the form [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:... or alternatively the wildcard '*' can be used to throttle all replicas for this topic.</td></td><td>list</td></td><td>""</td></td><td>[partitionId],[brokerId]:[partitionId],[brokerId]:...</td></td><td>follower.replication.throttled.replica [...]
+<tr>
+<td>index.interval.bytes</td></td><td>This setting controls how frequently Kafka adds an index entry to it's offset index. The default setting ensures that we index a message roughly every 4096 bytes. More indexing allows reads to jump closer to the exact position in the log but makes the index larger. You probably don't need to change this.</td></td><td>int</td></td><td>4096</td></td><td>[0,...]</td></td><td>log.index.interval.bytes</td></td><td>medium</td></td></tr>
+<tr>
+<td>leader.replication.throttled.replicas</td></td><td>A list of replicas for which log replication should be throttled on the leader side. The list should describe a set of replicas in the form [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:... or alternatively the wildcard '*' can be used to throttle all replicas for this topic.</td></td><td>list</td></td><td>""</td></td><td>[partitionId],[brokerId]:[partitionId],[brokerId]:...</td></td><td>leader.replication.throttled.replicas</td> [...]
+<tr>
+<td>max.message.bytes</td></td><td><p>The largest record batch size allowed by Kafka. If this is increased and there are consumers older than 0.10.2, the consumers' fetch size must also be increased so that the they can fetch record batches this large.</p><p>In the latest message format version, records are always grouped into batches for efficiency. In previous message format versions, uncompressed records are not grouped into batches and this limit only applies to a single record in th [...]
+<tr>
+<td>message.format.version</td></td><td>Specify the message format version the broker will use to append messages to the logs. The value should be a valid ApiVersion. Some examples are: 0.8.2, 0.9.0.0, 0.10.0, check ApiVersion for more details. By setting a particular message format version, the user is certifying that all the existing messages on disk are smaller or equal than the specified version. Setting this value incorrectly will cause consumers with older versions to break as they [...]
+<tr>
+<td>message.timestamp.difference.max.ms</td></td><td>The maximum difference allowed between the timestamp when a broker receives a message and the timestamp specified in the message. If message.timestamp.type=CreateTime, a message will be rejected if the difference in timestamp exceeds this threshold. This configuration is ignored if message.timestamp.type=LogAppendTime.</td></td><td>long</td></td><td>9223372036854775807</td></td><td>[0,...]</td></td><td>log.message.timestamp.difference. [...]
+<tr>
+<td>message.timestamp.type</td></td><td>Define whether the timestamp in the message is message create time or log append time. The value should be either `CreateTime` or `LogAppendTime`</td></td><td>string</td></td><td>CreateTime</td></td><td></td></td><td>log.message.timestamp.type</td></td><td>medium</td></td></tr>
+<tr>
+<td>min.cleanable.dirty.ratio</td></td><td>This configuration controls how frequently the log compactor will attempt to clean the log (assuming <a href="#compaction">log compaction</a> is enabled). By default we will avoid cleaning a log where more than 50% of the log has been compacted. This ratio bounds the maximum space wasted in the log by duplicates (at 50% at most 50% of the log could be duplicates). A higher ratio will mean fewer, more efficient cleanings but will mean more wasted [...]
+<tr>
+<td>min.compaction.lag.ms</td></td><td>The minimum time a message will remain uncompacted in the log. Only applicable for logs that are being compacted.</td></td><td>long</td></td><td>0</td></td><td>[0,...]</td></td><td>log.cleaner.min.compaction.lag.ms</td></td><td>medium</td></td></tr>
+<tr>
+<td>min.insync.replicas</td></td><td>When a producer sets acks to "all" (or "-1"), this configuration specifies the minimum number of replicas that must acknowledge a write for the write to be considered successful. If this minimum cannot be met, then the producer will raise an exception (either NotEnoughReplicas or NotEnoughReplicasAfterAppend).<br>When used together, min.insync.replicas and acks allow you to enforce greater durability guarantees. A typical scenario would be to create a [...]
+<tr>
+<td>preallocate</td></td><td>True if we should preallocate the file on disk when creating a new log segment.</td></td><td>boolean</td></td><td>false</td></td><td></td></td><td>log.preallocate</td></td><td>medium</td></td></tr>
+<tr>
+<td>retention.bytes</td></td><td>This configuration controls the maximum size a partition (which consists of log segments) can grow to before we will discard old log segments to free up space if we are using the "delete" retention policy. By default there is no size limit only a time limit. Since this limit is enforced at the partition level, multiply it by the number of partitions to compute the topic retention in bytes.</td></td><td>long</td></td><td>-1</td></td><td></td></td><td>log.r [...]
+<tr>
+<td>retention.ms</td></td><td>This configuration controls the maximum time we will retain a log before we will discard old log segments to free up space if we are using the "delete" retention policy. This represents an SLA on how soon consumers must read their data.</td></td><td>long</td></td><td>604800000</td></td><td></td></td><td>log.retention.ms</td></td><td>medium</td></td></tr>
+<tr>
+<td>segment.bytes</td></td><td>This configuration controls the segment file size for the log. Retention and cleaning is always done a file at a time so a larger segment size means fewer files but less granular control over retention.</td></td><td>int</td></td><td>1073741824</td></td><td>[14,...]</td></td><td>log.segment.bytes</td></td><td>medium</td></td></tr>
+<tr>
+<td>segment.index.bytes</td></td><td>This configuration controls the size of the index that maps offsets to file positions. We preallocate this index file and shrink it only after log rolls. You generally should not need to change this setting.</td></td><td>int</td></td><td>10485760</td></td><td>[0,...]</td></td><td>log.index.size.max.bytes</td></td><td>medium</td></td></tr>
+<tr>
+<td>segment.jitter.ms</td></td><td>The maximum random jitter subtracted from the scheduled segment roll time to avoid thundering herds of segment rolling</td></td><td>long</td></td><td>0</td></td><td>[0,...]</td></td><td>log.roll.jitter.ms</td></td><td>medium</td></td></tr>
+<tr>
+<td>segment.ms</td></td><td>This configuration controls the period of time after which Kafka will force the log to roll even if the segment file isn't full to ensure that retention can delete or compact old data.</td></td><td>long</td></td><td>604800000</td></td><td>[0,...]</td></td><td>log.roll.ms</td></td><td>medium</td></td></tr>
+<tr>
+<td>unclean.leader.election.enable</td></td><td>Indicates whether to enable replicas not in the ISR set to be elected as leader as a last resort, even though doing so may result in data loss.</td></td><td>boolean</td></td><td>false</td></td><td></td></td><td>unclean.leader.election.enable</td></td><td>medium</td></td></tr>
+</tbody></table>
diff --git a/11/images/consumer-groups.png b/11/images/consumer-groups.png
new file mode 100644
index 0000000..16fe293
Binary files /dev/null and b/11/images/consumer-groups.png differ
diff --git a/11/images/icons/NYT.jpg b/11/images/icons/NYT.jpg
new file mode 100644
index 0000000..f4a7e8f
Binary files /dev/null and b/11/images/icons/NYT.jpg differ
diff --git a/11/images/icons/architecture--white.png b/11/images/icons/architecture--white.png
new file mode 100644
index 0000000..98b1b03
Binary files /dev/null and b/11/images/icons/architecture--white.png differ
diff --git a/11/images/icons/architecture.png b/11/images/icons/architecture.png
new file mode 100644
index 0000000..6f9fd40
Binary files /dev/null and b/11/images/icons/architecture.png differ
diff --git a/11/images/icons/documentation--white.png b/11/images/icons/documentation--white.png
new file mode 100644
index 0000000..1e8fd97
Binary files /dev/null and b/11/images/icons/documentation--white.png differ
diff --git a/11/images/icons/documentation.png b/11/images/icons/documentation.png
new file mode 100644
index 0000000..8d9da19
Binary files /dev/null and b/11/images/icons/documentation.png differ
diff --git a/11/images/icons/line.png b/11/images/icons/line.png
new file mode 100755
index 0000000..4587d21
Binary files /dev/null and b/11/images/icons/line.png differ
diff --git a/11/images/icons/new-york.png b/11/images/icons/new-york.png
new file mode 100755
index 0000000..42a4b0b
Binary files /dev/null and b/11/images/icons/new-york.png differ
diff --git a/11/images/icons/rabobank.png b/11/images/icons/rabobank.png
new file mode 100755
index 0000000..ddad710
Binary files /dev/null and b/11/images/icons/rabobank.png differ
diff --git a/11/images/icons/tutorials--white.png b/11/images/icons/tutorials--white.png
new file mode 100644
index 0000000..97a0c04
Binary files /dev/null and b/11/images/icons/tutorials--white.png differ
diff --git a/11/images/icons/tutorials.png b/11/images/icons/tutorials.png
new file mode 100644
index 0000000..983da6c
Binary files /dev/null and b/11/images/icons/tutorials.png differ
diff --git a/11/images/icons/zalando.png b/11/images/icons/zalando.png
new file mode 100755
index 0000000..719a7dc
Binary files /dev/null and b/11/images/icons/zalando.png differ
diff --git a/11/images/kafka-apis.png b/11/images/kafka-apis.png
new file mode 100644
index 0000000..db6053c
Binary files /dev/null and b/11/images/kafka-apis.png differ
diff --git a/11/images/kafka_log.png b/11/images/kafka_log.png
new file mode 100644
index 0000000..75abd96
Binary files /dev/null and b/11/images/kafka_log.png differ
diff --git a/11/images/kafka_multidc.png b/11/images/kafka_multidc.png
new file mode 100644
index 0000000..7bc56f4
Binary files /dev/null and b/11/images/kafka_multidc.png differ
diff --git a/11/images/kafka_multidc_complex.png b/11/images/kafka_multidc_complex.png
new file mode 100644
index 0000000..ab88deb
Binary files /dev/null and b/11/images/kafka_multidc_complex.png differ
diff --git a/11/images/log_anatomy.png b/11/images/log_anatomy.png
new file mode 100644
index 0000000..a649499
Binary files /dev/null and b/11/images/log_anatomy.png differ
diff --git a/11/images/log_cleaner_anatomy.png b/11/images/log_cleaner_anatomy.png
new file mode 100644
index 0000000..fb425b0
Binary files /dev/null and b/11/images/log_cleaner_anatomy.png differ
diff --git a/11/images/log_compaction.png b/11/images/log_compaction.png
new file mode 100644
index 0000000..4e4a833
Binary files /dev/null and b/11/images/log_compaction.png differ
diff --git a/11/images/log_consumer.png b/11/images/log_consumer.png
new file mode 100644
index 0000000..fbc45f2
Binary files /dev/null and b/11/images/log_consumer.png differ
diff --git a/11/images/mirror-maker.png b/11/images/mirror-maker.png
new file mode 100644
index 0000000..8f76b1f
Binary files /dev/null and b/11/images/mirror-maker.png differ
diff --git a/11/images/producer_consumer.png b/11/images/producer_consumer.png
new file mode 100644
index 0000000..4b10cc9
Binary files /dev/null and b/11/images/producer_consumer.png differ
diff --git a/11/images/streams-architecture-overview.jpg b/11/images/streams-architecture-overview.jpg
new file mode 100644
index 0000000..9222079
Binary files /dev/null and b/11/images/streams-architecture-overview.jpg differ
diff --git a/11/images/streams-architecture-states.jpg b/11/images/streams-architecture-states.jpg
new file mode 100644
index 0000000..fde12db
Binary files /dev/null and b/11/images/streams-architecture-states.jpg differ
diff --git a/11/images/streams-architecture-tasks.jpg b/11/images/streams-architecture-tasks.jpg
new file mode 100644
index 0000000..2e957f9
Binary files /dev/null and b/11/images/streams-architecture-tasks.jpg differ
diff --git a/11/images/streams-architecture-threads.jpg b/11/images/streams-architecture-threads.jpg
new file mode 100644
index 0000000..d5f10db
Binary files /dev/null and b/11/images/streams-architecture-threads.jpg differ
diff --git a/11/images/streams-architecture-topology.jpg b/11/images/streams-architecture-topology.jpg
new file mode 100644
index 0000000..f42e8cd
Binary files /dev/null and b/11/images/streams-architecture-topology.jpg differ
diff --git a/11/images/streams-cache-and-commit-interval.png b/11/images/streams-cache-and-commit-interval.png
new file mode 100644
index 0000000..a663bc6
Binary files /dev/null and b/11/images/streams-cache-and-commit-interval.png differ
diff --git a/11/images/streams-concepts-topology.jpg b/11/images/streams-concepts-topology.jpg
new file mode 100644
index 0000000..832f6d4
Binary files /dev/null and b/11/images/streams-concepts-topology.jpg differ
diff --git a/11/images/streams-elastic-scaling-1.png b/11/images/streams-elastic-scaling-1.png
new file mode 100644
index 0000000..7823ac1
Binary files /dev/null and b/11/images/streams-elastic-scaling-1.png differ
diff --git a/11/images/streams-elastic-scaling-2.png b/11/images/streams-elastic-scaling-2.png
new file mode 100644
index 0000000..374b5ff
Binary files /dev/null and b/11/images/streams-elastic-scaling-2.png differ
diff --git a/11/images/streams-elastic-scaling-3.png b/11/images/streams-elastic-scaling-3.png
new file mode 100644
index 0000000..0b4adaf
Binary files /dev/null and b/11/images/streams-elastic-scaling-3.png differ
diff --git a/11/images/streams-interactive-queries-01.png b/11/images/streams-interactive-queries-01.png
new file mode 100644
index 0000000..d5d5031
Binary files /dev/null and b/11/images/streams-interactive-queries-01.png differ
diff --git a/11/images/streams-interactive-queries-02.png b/11/images/streams-interactive-queries-02.png
new file mode 100644
index 0000000..ea894b6
Binary files /dev/null and b/11/images/streams-interactive-queries-02.png differ
diff --git a/11/images/streams-interactive-queries-03.png b/11/images/streams-interactive-queries-03.png
new file mode 100644
index 0000000..403e3ae
Binary files /dev/null and b/11/images/streams-interactive-queries-03.png differ
diff --git a/11/images/streams-interactive-queries-api-01.png b/11/images/streams-interactive-queries-api-01.png
new file mode 100644
index 0000000..2b4aaed
Binary files /dev/null and b/11/images/streams-interactive-queries-api-01.png differ
diff --git a/11/images/streams-interactive-queries-api-02.png b/11/images/streams-interactive-queries-api-02.png
new file mode 100644
index 0000000..e5e7527
Binary files /dev/null and b/11/images/streams-interactive-queries-api-02.png differ
diff --git a/11/images/streams-session-windows-01.png b/11/images/streams-session-windows-01.png
new file mode 100644
index 0000000..2d711d8
Binary files /dev/null and b/11/images/streams-session-windows-01.png differ
diff --git a/11/images/streams-session-windows-02.png b/11/images/streams-session-windows-02.png
new file mode 100644
index 0000000..6c0382f
Binary files /dev/null and b/11/images/streams-session-windows-02.png differ
diff --git a/11/images/streams-stateful_operations.png b/11/images/streams-stateful_operations.png
new file mode 100644
index 0000000..b0fe3de
Binary files /dev/null and b/11/images/streams-stateful_operations.png differ
diff --git a/11/images/streams-table-duality-01.png b/11/images/streams-table-duality-01.png
new file mode 100644
index 0000000..4fa4d1b
Binary files /dev/null and b/11/images/streams-table-duality-01.png differ
diff --git a/11/images/streams-table-duality-02.png b/11/images/streams-table-duality-02.png
new file mode 100644
index 0000000..4e805c1
Binary files /dev/null and b/11/images/streams-table-duality-02.png differ
diff --git a/11/images/streams-table-duality-03.png b/11/images/streams-table-duality-03.png
new file mode 100644
index 0000000..b0b04f5
Binary files /dev/null and b/11/images/streams-table-duality-03.png differ
diff --git a/11/images/streams-table-updates-01.png b/11/images/streams-table-updates-01.png
new file mode 100644
index 0000000..3a2c35e
Binary files /dev/null and b/11/images/streams-table-updates-01.png differ
diff --git a/11/images/streams-table-updates-02.png b/11/images/streams-table-updates-02.png
new file mode 100644
index 0000000..a0a5b1f
Binary files /dev/null and b/11/images/streams-table-updates-02.png differ
diff --git a/11/images/streams-time-windows-hopping.png b/11/images/streams-time-windows-hopping.png
new file mode 100644
index 0000000..5fcb9d2
Binary files /dev/null and b/11/images/streams-time-windows-hopping.png differ
diff --git a/11/images/streams-time-windows-tumbling.png b/11/images/streams-time-windows-tumbling.png
new file mode 100644
index 0000000..571ab79
Binary files /dev/null and b/11/images/streams-time-windows-tumbling.png differ
diff --git a/11/images/streams-welcome.png b/11/images/streams-welcome.png
new file mode 100644
index 0000000..63918c4
Binary files /dev/null and b/11/images/streams-welcome.png differ
diff --git a/11/images/tracking_high_level.png b/11/images/tracking_high_level.png
new file mode 100644
index 0000000..b643230
Binary files /dev/null and b/11/images/tracking_high_level.png differ
diff --git a/11/implementation.html b/11/implementation.html
new file mode 100644
index 0000000..8b97aa0
--- /dev/null
+++ b/11/implementation.html
@@ -0,0 +1,319 @@
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<script id="implementation-template" type="text/x-handlebars-template">
+ <h3><a id="networklayer" href="#networklayer">5.1 Network Layer</a></h3>
+ <p>
+ The network layer is a fairly straight-forward NIO server, and will not be described in great detail. The sendfile implementation is done by giving the <code>MessageSet</code> interface a <code>writeTo</code> method. This allows the file-backed message set to use the more efficient <code>transferTo</code> implementation instead of an in-process buffered write. The threading model is a single acceptor thread and <i>N</i> processor threads which handle a fixed number of connections eac [...]
+ </p>
+ <h3><a id="messages" href="#messages">5.2 Messages</a></h3>
+ <p>
+ Messages consist of a variable-length header, a variable length opaque key byte array and a variable length opaque value byte array. The format of the header is described in the following section.
+ Leaving the key and value opaque is the right decision: there is a great deal of progress being made on serialization libraries right now, and any particular choice is unlikely to be right for all uses. Needless to say a particular application using Kafka would likely mandate a particular serialization type as part of its usage. The <code>RecordBatch</code> interface is simply an iterator over messages with specialized methods for bulk reading and writing to an NIO <code>Channel</code>.</p>
+
+ <h3><a id="messageformat" href="#messageformat">5.3 Message Format</a></h3>
+ <p>
+ Messages (aka Records) are always written in batches. The technical term for a batch of messages is a record batch, and a record batch contains one or more records. In the degenerate case, we could have a record batch containing a single record.
+ Record batches and records have their own headers. The format of each is described below for Kafka version 0.11.0 and later (message format version v2, or magic=2). <a href="https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol#AGuideToTheKafkaProtocol-Messagesets">Click here</a> for details about message formats 0 and 1.</p>
+
+ <h4><a id="recordbatch" href="#recordbatch">5.3.1 Record Batch</a></h4>
+ <p> The following is the on-disk format of a RecordBatch. </p>
+ <p><pre class="brush: java;">
+ baseOffset: int64
+ batchLength: int32
+ partitionLeaderEpoch: int32
+ magic: int8 (current magic value is 2)
+ crc: int32
+ attributes: int16
+ bit 0~2:
+ 0: no compression
+ 1: gzip
+ 2: snappy
+ 3: lz4
+ bit 3: timestampType
+ bit 4: isTransactional (0 means not transactional)
+ bit 5: isControlBatch (0 means not a control batch)
+ bit 6~15: unused
+ lastOffsetDelta: int32
+ firstTimestamp: int64
+ maxTimestamp: int64
+ producerId: int64
+ producerEpoch: int16
+ baseSequence: int32
+ records: [Record]
+ </pre></p>
+ <p> Note that when compression is enabled, the compressed record data is serialized directly following the count of the number of records. </p>
+
+ <p>The CRC covers the data from the attributes to the end of the batch (i.e. all the bytes that follow the CRC). It is located after the magic byte, which
+ means that clients must parse the magic byte before deciding how to interpret the bytes between the batch length and the magic byte. The partition leader
+ epoch field is not included in the CRC computation to avoid the need to recompute the CRC when this field is assigned for every batch that is received by
+ the broker. The CRC-32C (Castagnoli) polynomial is used for the computation.</p>
+
+ <p>On compaction: unlike the older message formats, magic v2 and above preserves the first and last offset/sequence numbers from the original batch when the log is cleaned. This is required in order to be able to restore the
+ producer's state when the log is reloaded. If we did not retain the last sequence number, for example, then after a partition leader failure, the producer might see an OutOfSequence error. The base sequence number must
+ be preserved for duplicate checking (the broker checks incoming Produce requests for duplicates by verifying that the first and last sequence numbers of the incoming batch match the last from that producer). As a result,
+ it is possible to have empty batches in the log when all the records in the batch are cleaned but batch is still retained in order to preserve a producer's last sequence number. One oddity here is that the baseTimestamp
+ field is not preserved during compaction, so it will change if the first record in the batch is compacted away.</p>
+
+ <h5><a id="controlbatch" href="#controlbatch">5.3.1.1 Control Batches</a></h5>
+ <p>A control batch contains a single record called the control record. Control records should not be passed on to applications. Instead, they are used by consumers to filter out aborted transactional messages.</p>
+ <p> The key of a control record conforms to the following schema: </p>
+ <p><pre class="brush: java">
+ version: int16 (current version is 0)
+ type: int16 (0 indicates an abort marker, 1 indicates a commit)
+ </pre></p>
+ <p>The schema for the value of a control record is dependent on the type. The value is opaque to clients.</p>
+
+ <h4><a id="record" href="#record">5.3.2 Record</a></h4>
+ <p>Record level headers were introduced in Kafka 0.11.0. The on-disk format of a record with Headers is delineated below. </p>
+ <p><pre class="brush: java;">
+ length: varint
+ attributes: int8
+ bit 0~7: unused
+ timestampDelta: varint
+ offsetDelta: varint
+ keyLength: varint
+ key: byte[]
+ valueLen: varint
+ value: byte[]
+ Headers => [Header]
+ </pre></p>
+ <h5><a id="recordheader" href="#recordheader">5.4.2.1 Record Header</a></h5>
+ <p><pre class="brush: java;">
+ headerKeyLength: varint
+ headerKey: String
+ headerValueLength: varint
+ Value: byte[]
+ </pre></p>
+ <p>We use the same varint encoding as Protobuf. More information on the latter can be found <a href="https://developers.google.com/protocol-buffers/docs/encoding#varints">here</a>. The count of headers in a record
+ is also encoded as a varint.</p>
+
+ <h3><a id="log" href="#log">5.4 Log</a></h3>
+ <p>
+ A log for a topic named "my_topic" with two partitions consists of two directories (namely <code>my_topic_0</code> and <code>my_topic_1</code>) populated with data files containing the messages for that topic. The format of the log files is a sequence of "log entries""; each log entry is a 4 byte integer <i>N</i> storing the message length which is followed by the <i>N</i> message bytes. Each message is uniquely identified by a 64-bit integer <i>offset</i> giving the byte position of [...]
+ </p>
+ <p>
+ The exact binary format for records is versioned and maintained as a standard interface so record batches can be transferred between producer, broker, and client without recopying or conversion when desirable. The previous section included details about the on-disk format of records.</p>
+ </p>
+ <p>
+ The use of the message offset as the message id is unusual. Our original idea was to use a GUID generated by the producer, and maintain a mapping from GUID to offset on each broker. But since a consumer must maintain an ID for each server, the global uniqueness of the GUID provides no value. Furthermore, the complexity of maintaining the mapping from a random id to an offset requires a heavy weight index structure which must be synchronized with disk, essentially requiring a full per [...]
+ </p>
+ <img class="centered" src="/{{version}}/images/kafka_log.png">
+ <h4><a id="impl_writes" href="#impl_writes">Writes</a></h4>
+ <p>
+ The log allows serial appends which always go to the last file. This file is rolled over to a fresh file when it reaches a configurable size (say 1GB). The log takes two configuration parameters: <i>M</i>, which gives the number of messages to write before forcing the OS to flush the file to disk, and <i>S</i>, which gives a number of seconds after which a flush is forced. This gives a durability guarantee of losing at most <i>M</i> messages or <i>S</i> seconds of data in the event o [...]
+ </p>
+ <h4><a id="impl_reads" href="#impl_reads">Reads</a></h4>
+ <p>
+ Reads are done by giving the 64-bit logical offset of a message and an <i>S</i>-byte max chunk size. This will return an iterator over the messages contained in the <i>S</i>-byte buffer. <i>S</i> is intended to be larger than any single message, but in the event of an abnormally large message, the read can be retried multiple times, each time doubling the buffer size, until the message is read successfully. A maximum message and buffer size can be specified to make the server reject [...]
+ </p>
+ <p>
+ The actual process of reading from an offset requires first locating the log segment file in which the data is stored, calculating the file-specific offset from the global offset value, and then reading from that file offset. The search is done as a simple binary search variation against an in-memory range maintained for each file.
+ </p>
+ <p>
+ The log provides the capability of getting the most recently written message to allow clients to start subscribing as of "right now". This is also useful in the case the consumer fails to consume its data within its SLA-specified number of days. In this case when the client attempts to consume a non-existent offset it is given an OutOfRangeException and can either reset itself or fail as appropriate to the use case.
+ </p>
+
+ <p> The following is the format of the results sent to the consumer.
+
+ <pre class="brush: text;">
+ MessageSetSend (fetch result)
+
+ total length : 4 bytes
+ error code : 2 bytes
+ message 1 : x bytes
+ ...
+ message n : x bytes
+ </pre>
+
+ <pre class="brush: text;">
+ MultiMessageSetSend (multiFetch result)
+
+ total length : 4 bytes
+ error code : 2 bytes
+ messageSetSend 1
+ ...
+ messageSetSend n
+ </pre>
+ <h4><a id="impl_deletes" href="#impl_deletes">Deletes</a></h4>
+ <p>
+ Data is deleted one log segment at a time. The log manager allows pluggable delete policies to choose which files are eligible for deletion. The current policy deletes any log with a modification time of more than <i>N</i> days ago, though a policy which retained the last <i>N</i> GB could also be useful. To avoid locking reads while still allowing deletes that modify the segment list we use a copy-on-write style segment list implementation that provides consistent views to allow a b [...]
+ </p>
+ <h4><a id="impl_guarantees" href="#impl_guarantees">Guarantees</a></h4>
+ <p>
+ The log provides a configuration parameter <i>M</i> which controls the maximum number of messages that are written before forcing a flush to disk. On startup a log recovery process is run that iterates over all messages in the newest log segment and verifies that each message entry is valid. A message entry is valid if the sum of its size and offset are less than the length of the file AND the CRC32 of the message payload matches the CRC stored with the message. In the event corrupti [...]
+ </p>
+ <p>
+ Note that two kinds of corruption must be handled: truncation in which an unwritten block is lost due to a crash, and corruption in which a nonsense block is ADDED to the file. The reason for this is that in general the OS makes no guarantee of the write order between the file inode and the actual block data so in addition to losing written data the file can gain nonsense data if the inode is updated with a new size but a crash occurs before the block containing that data is written. [...]
+ </p>
+
+ <h3><a id="distributionimpl" href="#distributionimpl">5.5 Distribution</a></h3>
+ <h4><a id="impl_offsettracking" href="#impl_offsettracking">Consumer Offset Tracking</a></h4>
+ <p>
+ The high-level consumer tracks the maximum offset it has consumed in each partition and periodically commits its offset vector so that it can resume from those offsets in the event of a restart. Kafka provides the option to store all the offsets for a given consumer group in a designated broker (for that group) called the <i>offset manager</i>. i.e., any consumer instance in that consumer group should send its offset commits and fetches to that offset manager (broker). The high-level [...]
+ </p>
+
+ <p>
+ When the offset manager receives an OffsetCommitRequest, it appends the request to a special <a href="#compaction">compacted</a> Kafka topic named <i>__consumer_offsets</i>. The offset manager sends a successful offset commit response to the consumer only after all the replicas of the offsets topic receive the offsets. In case the offsets fail to replicate within a configurable timeout, the offset commit will fail and the consumer may retry the commit after backing off. (This is done [...]
+ </p>
+
+ <p>
+ When the offset manager receives an offset fetch request, it simply returns the last committed offset vector from the offsets cache. In case the offset manager was just started or if it just became the offset manager for a new set of consumer groups (by becoming a leader for a partition of the offsets topic), it may need to load the offsets topic partition into the cache. In this case, the offset fetch will fail with an OffsetsLoadInProgress exception and the consumer may retry the O [...]
+ </p>
+
+ <h5><a id="offsetmigration" href="#offsetmigration">Migrating offsets from ZooKeeper to Kafka</a></h5>
+ <p>
+ Kafka consumers in earlier releases store their offsets by default in ZooKeeper. It is possible to migrate these consumers to commit offsets into Kafka by following these steps:
+ <ol>
+ <li>Set <code>offsets.storage=kafka</code> and <code>dual.commit.enabled=true</code> in your consumer config.
+ </li>
+ <li>Do a rolling bounce of your consumers and then verify that your consumers are healthy.
+ </li>
+ <li>Set <code>dual.commit.enabled=false</code> in your consumer config.
+ </li>
+ <li>Do a rolling bounce of your consumers and then verify that your consumers are healthy.
+ </li>
+ </ol>
+ A roll-back (i.e., migrating from Kafka back to ZooKeeper) can also be performed using the above steps if you set <code>offsets.storage=zookeeper</code>.
+ </p>
+
+ <h4><a id="impl_zookeeper" href="#impl_zookeeper">ZooKeeper Directories</a></h4>
+ <p>
+ The following gives the ZooKeeper structures and algorithms used for co-ordination between consumers and brokers.
+ </p>
+
+ <h4><a id="impl_zknotation" href="#impl_zknotation">Notation</a></h4>
+ <p>
+ When an element in a path is denoted [xyz], that means that the value of xyz is not fixed and there is in fact a ZooKeeper znode for each possible value of xyz. For example /topics/[topic] would be a directory named /topics containing a sub-directory for each topic name. Numerical ranges are also given such as [0...5] to indicate the subdirectories 0, 1, 2, 3, 4. An arrow -> is used to indicate the contents of a znode. For example /hello -> world would indicate a znode /hello contain [...]
+ </p>
+
+ <h4><a id="impl_zkbroker" href="#impl_zkbroker">Broker Node Registry</a></h4>
+ <pre class="brush: json;">
+ /brokers/ids/[0...N] --> {"jmx_port":...,"timestamp":...,"endpoints":[...],"host":...,"version":...,"port":...} (ephemeral node)
+ </pre>
+ <p>
+ This is a list of all present broker nodes, each of which provides a unique logical broker id which identifies it to consumers (which must be given as part of its configuration). On startup, a broker node registers itself by creating a znode with the logical broker id under /brokers/ids. The purpose of the logical broker id is to allow a broker to be moved to a different physical machine without affecting consumers. An attempt to register a broker id that is already in use (say becau [...]
+ </p>
+ <p>
+ Since the broker registers itself in ZooKeeper using ephemeral znodes, this registration is dynamic and will disappear if the broker is shutdown or dies (thus notifying consumers it is no longer available).
+ </p>
+ <h4><a id="impl_zktopic" href="#impl_zktopic">Broker Topic Registry</a></h4>
+ <pre class="brush: json;">
+ /brokers/topics/[topic]/partitions/[0...N]/state --> {"controller_epoch":...,"leader":...,"version":...,"leader_epoch":...,"isr":[...]} (ephemeral node)
+ </pre>
+
+ <p>
+ Each broker registers itself under the topics it maintains and stores the number of partitions for that topic.
+ </p>
+
+ <h4><a id="impl_zkconsumers" href="#impl_zkconsumers">Consumers and Consumer Groups</a></h4>
+ <p>
+ Consumers of topics also register themselves in ZooKeeper, in order to coordinate with each other and balance the consumption of data. Consumers can also store their offsets in ZooKeeper by setting <code>offsets.storage=zookeeper</code>. However, this offset storage mechanism will be deprecated in a future release. Therefore, it is recommended to <a href="#offsetmigration">migrate offsets storage to Kafka</a>.
+ </p>
+
+ <p>
+ Multiple consumers can form a group and jointly consume a single topic. Each consumer in the same group is given a shared group_id.
+ For example if one consumer is your foobar process, which is run across three machines, then you might assign this group of consumers the id "foobar". This group id is provided in the configuration of the consumer, and is your way to tell the consumer which group it belongs to.
+ </p>
+
+ <p>
+ The consumers in a group divide up the partitions as fairly as possible, each partition is consumed by exactly one consumer in a consumer group.
+ </p>
+
+ <h4><a id="impl_zkconsumerid" href="#impl_zkconsumerid">Consumer Id Registry</a></h4>
... 214099 lines suppressed ...
--
To stop receiving notification emails like this one, please contact
damianguy@apache.org.