# mulesoft Apache Kafka Connector - Full Documentation

<!-- document id=a4552ede4ce9ce8584899d3b5ca8d05322463ce5c4394194d44be408cf9fb755 url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-examples.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Apache Kafka 4.10 Examples

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following examples shows how to configure Apache Kafka Connector:

- [Publish and Consume Example](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-publish-consume-example)  
  Use the **Publish** and **Consume** to publish a message to Apache Kafka and then retrieve it.

- [Integrate Confluent Schema Registry](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-configure-confluent-example)  
  Configure Confluent Schema Registry via the **Additional Properties** field using Kafka Connector.

- [Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-bulk-publish-example)  
  Use **Bulk Publish** to publish multiple messages to Apache Kafka in one operation.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=daeff66230b3e3d31ffeaccba61b5055d1523a9e589f8df19f1157be6de2c671 url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-xml-maven.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Apache Kafka 4.10 XML and Maven Support

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

If you manually code a Mule app in XML either from the Anypoint Studio XML editor or from a text
editor, you can get access to the Anypoint Connector for Apache Kafka (Apache Kafka Connector) in
your app by adding reference statements to your XML Mule flow and in the Apache Maven `pom.xml`
file.

> [!NOTE] You can avoid this manual process by using Anypoint Studio. When you add the Apache Kafka
> Connector in Studio, Studio automatically populates the XML code with the Apache Kafka Connector
> namespace and schema location, and adds a dependency to the pom.xml file.

## Add a Namespace for the Connector

Paste the following into the header of your configuration XML, inside the `<mule>` tag:

```xml
http://www.mulesoft.org/schema/mule/kafka
http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd
```

This example shows how the namespace statements are placed in the `<mule>` XML block:

```xml
<mule xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
```

## Add a POM File Dependency

The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app.
If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to
this connector:

```xml
<dependency>
  <groupId>com.mulesoft.connectors</groupId>
  <artifactId>mule-kafka-connector</artifactId>
  <version>x.x.x</version>
  <classifier>mule-plugin</classifier>
</dependency>
```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Next

After completing your namespace and `pom.xml` file, you can try out the Apache Kafka
[Examples](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=de3dd8a338060e101b226a49ce48e680bbb51e7ded8b141cbc04803d71cf2549 url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-examples.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Apache Kafka 4.11 Examples

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following examples shows how to configure Apache Kafka Connector:

- [Publish and Consume Example](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-publish-consume-example)  
  Use the **Publish** and **Consume** to publish a message to Apache Kafka and then retrieve it.

- [Integrate Confluent Schema Registry](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-configure-confluent-example)  
  Configure Confluent Schema Registry via the **Additional Properties** field using Kafka Connector.

- [Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-bulk-publish-example)  
  Use **Bulk Publish** to publish multiple messages to Apache Kafka in one operation.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=d03bc6006e92f8995f098458c437cfcebf14bab0ae26b3ed3ece0e0d21133b93 url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-xml-maven.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Apache Kafka 4.11 XML and Maven Support

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

If you manually code a Mule app in XML either from the Anypoint Studio XML editor or from a text
editor, you can get access to the Anypoint Connector for Apache Kafka (Apache Kafka Connector) in
your app by adding reference statements to your XML Mule flow and in the Apache Maven `pom.xml`
file.

> [!NOTE] You can avoid this manual process by using Anypoint Studio. When you add the Apache Kafka
> Connector in Studio, Studio automatically populates the XML code with the Apache Kafka Connector
> namespace and schema location, and adds a dependency to the pom.xml file.

## Add a Namespace for the Connector

Paste the following into the header of your configuration XML, inside the `<mule>` tag:

```xml
http://www.mulesoft.org/schema/mule/kafka
http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd
```

This example shows how the namespace statements are placed in the `<mule>` XML block:

```xml
<mule xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
```

## Add a POM File Dependency

The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app.
If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to
this connector:

```xml
<dependency>
  <groupId>com.mulesoft.connectors</groupId>
  <artifactId>mule-kafka-connector</artifactId>
  <version>x.x.x</version>
  <classifier>mule-plugin</classifier>
</dependency>
```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Next

After completing your namespace and `pom.xml` file, you can try out the Apache Kafka
[Examples](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=2cf1f610b5270883dce9cea8808ff6b0a92f0c76638ea20090c05de351e27bf4 url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-examples.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Apache Kafka 4.12 Examples

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following examples shows how to configure Apache Kafka Connector:

- [Publish and Consume Example](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-publish-consume-example)  
  Use the **Publish** and **Consume** to publish a message to Apache Kafka and then retrieve it.

- [Integrate Confluent Schema Registry](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-configure-confluent-example)  
  Configure Confluent Schema Registry via the **Additional Properties** field using Kafka Connector.

- [Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-bulk-publish-example)  
  Use **Bulk Publish** to publish multiple messages to Apache Kafka in one operation.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=822ff670f29b7b98aa8698134e0fd7f9741c1673a17d6bdb108117a9f2a5a087 url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-xml-maven.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Apache Kafka 4.12 XML and Maven Support

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

If you manually code a Mule app in XML either from the Anypoint Studio XML editor or from a text
editor, you can get access to the Anypoint Connector for Apache Kafka (Apache Kafka Connector) in
your app by adding reference statements to your XML Mule flow and in the Apache Maven `pom.xml`
file.

> [!NOTE] You can avoid this manual process by using Anypoint Studio. When you add the Apache Kafka
> Connector in Studio, Studio automatically populates the XML code with the Apache Kafka Connector
> namespace and schema location, and adds a dependency to the pom.xml file.

## Add a Namespace for the Connector

Paste the following into the header of your configuration XML, inside the `<mule>` tag:

```xml
http://www.mulesoft.org/schema/mule/kafka
http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd
```

This example shows how the namespace statements are placed in the `<mule>` XML block:

```xml
<mule xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
```

## Add a POM File Dependency

The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app.
If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to
this connector:

```xml
<dependency>
  <groupId>com.mulesoft.connectors</groupId>
  <artifactId>mule-kafka-connector</artifactId>
  <version>x.x.x</version>
  <classifier>mule-plugin</classifier>
</dependency>
```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Next

After completing your namespace and `pom.xml` file, you can try out the Apache Kafka
[Examples](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=4ce483687111f047ad3d8c4e9b98e70a675789d93e77f09b466860c79cfe6915 url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-examples.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Apache Kafka 4.13 Examples

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following examples shows how to configure Apache Kafka Connector:

- [Publish and Consume Example](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-publish-consume-example)  
  Use the **Publish** and **Consume** to publish a message to Apache Kafka and then retrieve it.

- [Integrate Confluent Schema Registry](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-configure-confluent-example)  
  Configure Confluent Schema Registry via the **Additional Properties** field using Kafka Connector.

- [Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-bulk-publish-example)  
  Use **Bulk Publish** to publish multiple messages to Apache Kafka in one operation.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=c21ff02e70bce0798b2934f9241d9d47e435010c55bdd35c01ca4b1842e2a006 url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-xml-maven.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Apache Kafka 4.13 XML and Maven Support

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

If you manually code a Mule app in XML either from the Anypoint Studio XML editor or from a text
editor, you can get access to the Anypoint Connector for Apache Kafka (Apache Kafka Connector) in
your app by adding reference statements to your XML Mule flow and in the Apache Maven `pom.xml`
file.

> [!NOTE] You can avoid this manual process by using Anypoint Studio. When you add the Apache Kafka
> Connector in Studio, Studio automatically populates the XML code with the Apache Kafka Connector
> namespace and schema location, and adds a dependency to the pom.xml file.

## Add a Namespace for the Connector

Paste the following into the header of your configuration XML, inside the `<mule>` tag:

```xml
http://www.mulesoft.org/schema/mule/kafka
http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd
```

This example shows how the namespace statements are placed in the `<mule>` XML block:

```xml
<mule xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
```

## Add a POM File Dependency

The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app.
If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to
this connector:

```xml
<dependency>
  <groupId>com.mulesoft.connectors</groupId>
  <artifactId>mule-kafka-connector</artifactId>
  <version>x.x.x</version>
  <classifier>mule-plugin</classifier>
</dependency>
```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Next

After completing your namespace and `pom.xml` file, you can try out the Apache Kafka
[Examples](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=165edd827c41711199eb4354b53a7698ced17d8b6b36348216463c8408ace4ca url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-examples.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Apache Kafka 4.14 Examples

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following examples shows how to configure Apache Kafka Connector:

- [Publish and Consume Example](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-publish-consume-example)  
  Use the **Publish** and **Consume** to publish a message to Apache Kafka and then retrieve it.

- [Integrate Confluent Schema Registry](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-configure-confluent-example)  
  Configure Confluent Schema Registry via the **Additional Properties** field using Kafka Connector.

- [Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-bulk-publish-example)  
  Use **Bulk Publish** to publish multiple messages to Apache Kafka in one operation.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=64c201cfb688ca539e83986d7ca322bafe8b320495c358052d3dcc06becb79ff url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-xml-maven.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Apache Kafka 4.14 XML and Maven Support

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

If you manually code a Mule app in XML either from the Anypoint Studio XML editor or from a text
editor, you can get access to the Anypoint Connector for Apache Kafka (Apache Kafka Connector) in
your app by adding reference statements to your XML Mule flow and in the Apache Maven `pom.xml`
file.

> [!NOTE] You can avoid this manual process by using Anypoint Studio. When you add the Apache Kafka
> Connector in Studio, Studio automatically populates the XML code with the Apache Kafka Connector
> namespace and schema location, and adds a dependency to the pom.xml file.

## Add a Namespace for the Connector

Paste the following into the header of your configuration XML, inside the `<mule>` tag:

```xml
http://www.mulesoft.org/schema/mule/kafka
http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd
```

This example shows how the namespace statements are placed in the `<mule>` XML block:

```xml
<mule xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
```

## Add a POM File Dependency

The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app.
If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to
this connector:

```xml
<dependency>
  <groupId>com.mulesoft.connectors</groupId>
  <artifactId>mule-kafka-connector</artifactId>
  <version>x.x.x</version>
  <classifier>mule-plugin</classifier>
</dependency>
```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Next

After completing your namespace and `pom.xml` file, you can try out the Apache Kafka
[Examples](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=3edfc6862b1bf9a6da418601e8ad95be84f1d81b6f91bdea385f6d2b26a0220a url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-examples.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Apache Kafka 4.15 Examples

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following examples shows how to configure Apache Kafka Connector:

- [Publish and Consume Example](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-publish-consume-example)  
  Use the **Publish** and **Consume** to publish a message to Apache Kafka and then retrieve it.

- [Integrate Confluent Schema Registry](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-configure-confluent-example)  
  Configure Confluent Schema Registry via the **Additional Properties** field using Kafka Connector.

- [Configure AWS IAM Authentication](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-configure-aws-iam-example)  
  Configure SASL/AWS IAM authentication to connect to an Amazon MSK cluster.

- [Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-bulk-publish-example)  
  Use **Bulk Publish** to publish multiple messages to Apache Kafka in one operation.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=91af47f7e802a2995401ab23f73f42c22e87d7a7e9c00ec8e598b0e65331a641 url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-xml-maven.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Apache Kafka 4.15 XML and Maven Support

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

If you manually code a Mule app in XML either from the Anypoint Studio XML editor or from a text
editor, you can get access to the Anypoint Connector for Apache Kafka (Apache Kafka Connector) in
your app by adding reference statements to your XML Mule flow and in the Apache Maven `pom.xml`
file.

> [!NOTE] You can avoid this manual process by using Anypoint Studio. When you add the Apache Kafka
> Connector in Studio, Studio automatically populates the XML code with the Apache Kafka Connector
> namespace and schema location, and adds a dependency to the pom.xml file.

## Add a Namespace for the Connector

Paste the following into the header of your configuration XML, inside the `<mule>` tag:

```xml
http://www.mulesoft.org/schema/mule/kafka
http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd
```

This example shows how the namespace statements are placed in the `<mule>` XML block:

```xml
<mule xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
	xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:file="http://www.mulesoft.org/schema/mule/file"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/file
	http://www.mulesoft.org/schema/mule/file/current/mule-file.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
```

## Add a POM File Dependency

The Apache Maven `pom.xml` file generated by Anypoint Studio contains dependencies for a Mule app.
If you code a Mule app manually, include this XML snippet in your `pom.xml` file to enable access to
this connector:

```xml
<dependency>
  <groupId>com.mulesoft.connectors</groupId>
  <artifactId>mule-kafka-connector</artifactId>
  <version>x.x.x</version>
  <classifier>mule-plugin</classifier>
</dependency>
```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Next

After completing your namespace and `pom.xml` file, you can try out the Apache Kafka
[Examples](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=086d8e7d46e3fc709d8b37647ffad477b791b8eb9429d8a0633ad7734984eb70 url=/mulesoft/current/en-us/kafka-connector/4.10/index.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Apache Kafka Connector 4.10

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system and achieve seamless integration between your Mule app and a Kafka cluster,
using Mule runtime engine (Mule).

For compatibility information, see the Apache Kafka Connector Release Notes.

## Before You Begin

Before creating an app, you must:

- Have access to the Apache Kafka target resource and Anypoint Platform

- Understand how to create a Mule app using Anypoint Studio

- Have access to Apache Kafka to get values for the fields that appear in Studio

## Common Use Cases for the Connector

Common use cases for Apache Kafka Connector include:

- **Log Aggregation**

  Leverage the low-latency processing from Apache Kafka to collect logs from multiple services and
  make them available in a standard format to multiple consumers. For example, you can publish a
  message to Apache Kafka and then retrieve it.

- **Analysis and Metrics**

  Optimize your advertising budget by integrating Apache Kafka and your big data analytics solution
  to analyze end user activity, such as page views, clicks, shares, and so on, to serve relevant
  ads. For example, a department store can use a website activity tracker to improve the online
  shopping experience. The gathered data is sent to multiple departments for various computations.
  Each department reviews the received information to stay informed about what the customer is
  looking for and then provides recommendations accordingly.

- **Notifications and Alerts**

  Notify customers about various financial events, such as the recent amount of a transaction or
  more complex events like future investment suggestions based on integrations with credit agencies,
  location, and so on.

- **Time-Sensitive Applications**

  Build integration applications that are time-sensitive. For example, you can build an application
  that ensures that patients in a hospital receive the care they need in a timely manner with a
  hospital server that processes emergency requests for patient admissions and orders the requests
  based on priority determined by specified criteria. In this scenario, an application processes
  Apache Kafka messages in the order that they are received, relying on the order and idempotency of
  the messages sent through the queue. For example, a newsroom can use the Apache Kafka system to
  deliver the latest news. Retrieve the latest news by building an integration application by
  reading from the end of the Apache Kafka queue first.

For examples of these use cases, refer to
[Apache Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-examples).

### Publish-to Use Cases

With Kafka Connector, applications can publish binary messages to the Kafka server. Some examples of
use cases include:

- Publishing binary data to the Kafka server and the underlying topic.

- Setting the batch size of the data to publish to Kafka when working with large volumes of data.

  - To optimize for performance, companies can batch messages to send. Kafka stores the message
    until the batch size is reached and completes the send at that time.

- Configuring the message size to send to focus on optimal performance.

  - Kafka is not intended to process and handle large messages. Messages are typically in the 1 MB
    range and users set the size to avoid performance degradation. In the case of an error, the
    message is rejected.

- Blocking further commits on a configurable level of acknowledgment for the messages published to
  the Kafka server to ensure successful data transmission.

  - Acknowledgments enable users to ensure that the message is sent prior to publishing more
    messages. This is specifically useful in time-ordered or event-ordered messages, such as logs or
    patient drug administration orders. Ensuring that messages are sent in order helps the
    downstream application process the messages in the right order.

- Configuring how data is serialized during a publish.

- Securing messages sent during Mutual TLS.

The following lists the acceptance criteria for publishing:

- Publish a message to a Kafka topic.

- Configure the batch size and size of the message.

- Obtain an acknowledgment once publishing is complete at the configured level.

- Send the message securely via Mutual TLS.

- Configure the serialization type.

### Subscribe-from Use Cases

With Kafka Connector, applications can obtain messages from Kafka for further consumption
downstream. Some examples of use cases include:

Reading from Kafka:

- Subscribing to the Kafka server and the underlying group to read and consume messages for
  downstream processing.

- Subscribing to a specific Kafka partition to process messages.

  - Users with a high availability microservice don’t want to rely on Kafka’s rebalancing in the
    event of a failure.

  - If users have a local state associated with their partition, they want to process only that
    partition.

- Configuring the offset value to a set value or to the beginning or end of the topic.

  - Users have a local store and want to use that information to start processing their records.

  - Users have time-sensitive records and want to skip to the end if the application must be
    up-to-date or skip to the beginning if it is a new application processing the records.

- Reading the offset value from an alternate storage system on restart.

  - Users have a local store with the offset information and want to read the value from their local
    storage.

- Setting the interval for which to block the receipt of messages for varying downstream processing
  intervals.

Processing the messages:

- Ensuring there is no data loss when the downstream application crashes by manually configuring
  commits to have more control.

- Storing a commit value in a local store or in the Kafka storage and blocking until the store is
  successful.

- Storing an offset asynchronously in a local store or in the Kafka storage.

- Using Kafka’s in-built capability of load-balancing with multiple applications reading from the
  same group ID.

- Configuring the number of records to process in a single call.

The following lists the acceptance criteria for subscribing:

- Read a message from Kafka from a specific partition or topic.

- Read a message from Kafka after obtaining the offset from a local store.

- Read a message from the beginning of the queue, the end of the queue, and a pre-specified offset.

- Ensure a high level of performance when there is one consumer per thread. Multiple consumers exist
  in a single group.

## Audience

- Starting user

  To create a Mule app, see [Apache Kafka Studio Configuration](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-studio).

- Power user

  Read [XML and Maven Support](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-xml-maven) and [Examples](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-examples).

## Next

After you complete the prerequisites, you are ready to create an app with
[Anypoint Studio](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-studio).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange)

- [Apache Kafka Connector](https://www.mulesoft.com/exchange/com.mulesoft.connectors/mule-kafka-connector/)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=d5b3460d6e32d2fe072d1c2794b75714d4458765e8971ce1526eb915bec30b4d url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-config-topics.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Apache Kafka Connector 4.10 - Additional Configuration Information

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Set additional configuration for Anypoint Connector for Apache Kafka (Apache Kafka Connector).

## Configure a Custom Partitioner

You can configure a custom partitioner for Apache Kafka Connector in a Mule app:

1.  Use Maven to create a Java project and add the custom partitioner to it:

    ```java
    public class CustomPartitioner implements Partitioner {
    // Implementation
    }
    ```

2.  Add this dependency in the Mule app:

    ```java
    <dependencies>
     <dependency>
       <groupId>org.example</groupId>
       <artifactId>custom-partitioner</artifactId>
       <version>1.0-SNAPSHOT</version>
     </dependency>
    </dependencies>
    ```

3.  Add this dependency to `additionalPluginDependencies`:

    ```java
    <plugin>
     <groupId>org.mule.tools.maven</groupId>
     <artifactId>mule-maven-plugin</artifactId>
     <version>${mule.maven.plugin.version}</version>
     <extensions>true</extensions>
     <configuration>
      <additionalPluginDependencies>
      <plugin>
       <groupId>com.mulesoft.connectors</groupId>
       <artifactId>mule-kafka-connector</artifactId>
        <additionalDependencies>
         <dependency>
          <groupId>io.confluent</groupId>
          <artifactId>kafka-avro-serializer</artifactId>
          <version>7.6.1</version>
         </dependency>
         <dependency>
          <groupId>org.example</groupId>
          <artifactId>custom-partitioner</artifactId>
          <version>1.0-SNAPSHOT</version>
         </dependency>
        </additionalDependencies>
       </plugin>
       </additionalPluginDependencies>
       <classifier>mule-application</classifier>
     </configuration>
    </plugin>
    ```

4.  Add the custom partitioner to the producer configuration:

    ```java
    <kafka:producer-config name="Apache_Kafka_Producer_configuration"
        doc:name="Apache Kafka Producer configuration"
        doc:id="cb9de3c5-d6d2-4f9b-a255-75a9985bffb7">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="<kafka-url>" />
            </kafka:bootstrap-servers>
            <kafka:additional-properties>
                <kafka:additional-property key="key.serializer"
                    value="org.apache.kafka.common.serialization.StringSerializer" />
                <kafka:additional-property key="value.serializer"
                    value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer" />
                <kafka:additional-property key="schema.registry.url"
                    value="<schema-registry-url>" />
                <kafka:additional-property key="basic.auth.credentials.source"
                    value="USER_INFO" />
                <kafka:additional-property key="basic.auth.user.info"
                    value="user:pass" />
                <kafka:additional-property key="auto.register.schemas"
                    value="true" />
                <kafka:additional-property key="value.subject.name.strategy"
                    value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
                <kafka:additional-property key="partitioner.class"
                    value="org.example.CustomPartitioner" />
            </kafka:additional-properties>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>
    ```

## Next Step

After you complete configuring the connector, you can try the [examples](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=106eac05a41e2e6128d000815a8b16851b313d5a5e3a61ca40ea02decb49932a url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-reference.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Apache Kafka Connector 4.10 Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system. It provides seamless integration between your Mule app and an Apache Kafka
cluster, using Mule runtime engine (Mule).

> [!NOTE] When a **Message Listener** or a **Batch Message Listener** uses the `MANUAL`
> acknowledgement mode, you must use a **Commit** operation at the end of the flow when the flow
> finishes successfully (either because there were no errors or because there is an **On Error
> Continue** component in the flow).

> [!NOTE] Mule server notifications are not supported because the Kafka library used in the
> connector manages network disruptions internally.

## Consumer Configuration

Configuration for consumers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#consumer-plaintext">Consumer Plaintext Connection</a></p></li><li><p><a href="#consumer-sasl-kerberos">Consumer Kerberos Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-oauth-bearer-cc-connection">Consumer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#consumer-sasl-scram">Consumer SASL/SCRAM Connection</a></p></li><li><p><a href="#consumer-sasl-plain">Consumer SASL/PLAIN Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-token-connection">Consumer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>AUTO</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait to perform a poll if data is not available in the buffer (fetched). If no value is set, the poll is returned immediately with any records that are currently available in the buffer or else returns empty if there is no data. Must not be negative.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default listener poll timeout</strong> field. This combines with <strong>Poll Timeout</strong> to define the total timeout for the polling.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait for an operation to finish. If no value is set or a negative value is set, the operation waits forever.</p></div></div></td><td><div><div><p><code>-1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default operation timeout</strong> field. This combines with <strong>Operation Timeout</strong> to define the total default timeout for the operations that use this configuration.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely. Additionally, the
connector supports only
[RFC6749 standard](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3).

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default Group ID for all the Kafka Consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p>READ_UNCOMMITTED</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether internal topics matching a subscribed pattern is excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the reconnect backoff timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. You can override this field at the source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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 parameter can be overridden at source level.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum number of records returned on a poll call to the Kafka cluster. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 session.timeout.ms, 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 rebalances.</p></div></div></td><td><div><div><p>3</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch heartbeat interval time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 group.min.session.timeout.ms and group.max.session.timeout.ms.</p></div></div></td><td><div><div><p>10</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for session timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for connections maximum idle time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>The list of subscription regular expressions to subscribe to. This topics will be automatically rebalanced between the amount of consumers of the topic.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>The list of topic-partition pairs to assign. Note that there will be no automatic rebalance of the consumers</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The minimum amount of data the server should return for a fetch request. If insufficient data is available the request waits 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 data to accumulate which can improve server throughput a bit at the cost of some additional latency. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div></div></td><td><div><div><p>BYTE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 an absolute maximum. The maximum record batch size accepted by the broker is defined via message.max.bytes (broker config) or max.message.bytes (topic config). Note that the consumer performs multiple fetches in parallel. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 message.max.bytes (broker config) or max.message.bytes (topic config). See fetch.max.bytes for limiting the consumer request size.This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch maximum wait timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>User used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

---

## Producer Configuration

Configuration for producers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#producer-plaintext">Producer Plaintext Connection</a></p></li><li><p><a href="#producer-sasl-kerberos">Producer Kerberos Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-oauth-bearer-cc-connection">Producer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#producer-sasl-scram">Producer SASL/SCRAM Connection</a></p></li><li><p><a href="#producer-sasl-plain">Producer SASL/PLAIN Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-token-connection">Producer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default topic name to use by the producer operations, overridable at the operation’s configuration level.</p></div></div></td><td><div><div><p><code>defaultTopicName</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names..</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The producer attempts 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. No attempt will be made to batch records larger than this size. Requests sent to brokers will contain multiple batches, one for each partition with data available to be sent. A small batch size will make batching less common and may reduce throughput (a batch size of zero will disable batching entirely). A very large batch size may use memory a bit more wastefully as we will always allocate a buffer of the specified batch size in anticipation of additional records.</p></div></div></td><td><div><div><p>16</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the batch size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.block.ms after which it will throw an exception. 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 used for compression (if compression is enabled) as well as for maintaining in-flight requests. The default value in the Kafka docs is of 33554432 (32MB), but this should be capped to align with expected values for mule instances in cloudhub (v0.1 core)</p></div></div></td><td><div><div><p>1000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are none, gzip, snappy, lz4, or zstd. Compression is of full batches of data, so the efficacy of batching will also impact the compression ratio (more batching means better compression).</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the value specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the connections maximum idle scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>An upper bound on the time to report success or failure after a call to send() returns. This limits the total time that a record will be delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retriable send failures. The producer may report failure to send a record earlier than this config if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch which reached an earlier delivery expiration deadline. The value of this config should be greater than or equal to the sum of request.timeout.ms and linger.ms.</p></div></div></td><td><div><div><p>120</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the delivery timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection to be less than or equal to 5, retries to be greater than 0 and acks must be 'all'. If these values are not explicitly set by the user, suitable values will be chosen. If incompatible values are set, a ConnectionException will be thrown</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 waits for up to the given delay to allow other records to be sent so that the sends can be batched together. This can be thought of as analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching: once we get batch.size worth of records for a partition it is sent immediately regardless of this setting, however if we have fewer than this many bytes accumulated for this partition we will 'linger' for the specified time waiting for more records to show up. This setting defaults to 0 (i.e. no delay). Setting linger.ms=5, for example, would have the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p>0</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the linger time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls how long KafkaProducer.send() and KafkaProducer.partitionsFor() 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.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the maximum block time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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).</p></div></div></td><td><div><div><p>5</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer acknowledge mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>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</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection 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 second succeeds, then the records in the second batch may appear first. Note additionally that produce requests will be failed before the number of retries has been exhausted if the timeout configured by delivery.timeout.ms expires first before successful acknowledgment. Users should generally prefer to leave this config unset and instead use delivery.timeout.ms to control retry behavior.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the retry backoff timeout time scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry backoff timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the request timeout time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>The configuration controls which partitioning strategy is used when sending messages without providing a key or a partition.</p></div></div></td><td><div><div><p>DEFAULT</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>EncryptionType</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Consumer Sources

- [Batch Message Listener](#batch-message-listener)

- [Message Listener](#message-listener)

### Batch Message Listener

`<kafka:batch-message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a list of messages
to the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#Record">Record</a></p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#ConsumerContext">Consumer Context</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

> [!NOTE] The **Batch Message Listener** source does not support configurable streaming strategies
> because the source takes a batch of records as an input stream. The streaming strategy
> configuration is non-repeatable-stream by default for the source.

### Message Listener

`<kafka:message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a single message to
the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

## Consumer Operations

- [Commit](#commit)

- [Consume](#consume)

- [Seek](#seek)

### Commit

`<kafka:commit>`

Commits the offsets associated to a message or batch of messages consumed in a **Message Listener**.
This is a list or a single message consumed in the **Batch Message Listener** source.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumer commit key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Commit key of the last poll. This operation is valid only when used inside a flow that uses one of the sources (<strong>Batch Message Listener</strong> or <strong>Message Listener</strong>) which inserts this value as an attribute in the Mule event.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:INVALID\_ACK\_MODE

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ALREADY\_COMMITTED

- KAFKA:TIMEOUT

- KAFKA:SESSION\_NOT\_FOUND

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Consume

`<kafka:consume>`

Receives messages from one or more Kafka topics. This operation works similarly to the **Message
Listener** source, so all the operations that apply to that, apply to this operation as well.

> [!NOTE] The **Consume** operation does not return the `consumerCommitKey`.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Consumption timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>IMMEDIATE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ILLEGAL\_STATE

- KAFKA:TIMEOUT

- KAFKA:SERIALIZATION\_ERROR

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Seek

`<kafka:seek>`

Sets the current offset of the consumer for the given topic and partition to the provided offset
value.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which the <strong>Seek</strong> operation is performed.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number that has its offset modified.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:INVALID\_TOPIC

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

## Producer Operation

- [Bulk Publish](#bulkPublish)

- [Publish](#publish)

### Bulk Publish

`<kafka:bulk-publish>`

Publishes a bulk of messages to the specified Kafka topic, optionally specifying the partition, key,
and message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of <a href="#KafkaMessage">Kafka Message</a></p></div></div></td><td><div><div><p>List of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:AUTHENTICATION\_ERROR

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

### Publish

`<kafka:publish>`

Publishes a message to the specified Kafka topic, optionally specifying the partition, key, and
message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) Topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p><a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

## Object Types

- [Consumer Context](#ConsumerContext)

- [CRL File](#CrlFile)

- [Custom OCSP Responder](#CustomOcspResponder)

- [Expiration Policy](#ExpirationPolicy)

- [Kafka Message](#KafkaMessage)

- [Kafka Message Attributes](#KafkaMessageAttributes)

- [Kafka Message Metadata](#KafkaMessageMetadata)

- [Kafka Record Attributes](#KafkaRecordAttributes)

- [Keystore](#KeyStore)

- [Proxy Config Params](#ProxyConfigParams)

- [Reconnect](#Reconnect)

- [Reconnect Forever](#Reconnect-Forever)

- [Reconnection](#Reconnection)

- [Record](#Record)

- [Redelivery Policy](#RedeliveryPolicy)

- [Repeatable File Store Stream](#RepeatableFileStoreStream)

- [Repeatable In Memory Stream](#RepeatableInMemoryStream)

- [Standard Revocation Check](#StandardRevocationCheck)

- [Tcp Client Socket Params](#TcpClientSocketParams)

- [TLS](#Tls)

- [Topic Partition](#TopicPartition)

- [Truststore](#TrustStore)

### Consumer Context

Type for the consumer context.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### CRL File

Specifies the location of the certification revocation list (CRL) file.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the CRL file.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Custom OCSP Responder

Configures a custom OCSP responder for certification revocation checks.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Url</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>URL of the OCSP responder.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Cert Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the signing certificate for the OCSP response. If specified, the alias must be in the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Expiration Policy

Configures an expiration policy strategy.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Idle Time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Configures the maximum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Max Idle Time</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message

Represents a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaMessageAttributes">Kafka Message Attributes</a></p></div></div></td><td><div><div><p>Attributes associated with the Kafka message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Attributes

Represents the attributes of a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Headers of the Kafka message, represented as a map in which the key is a string and the value is an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Key of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the topic where the Kafka message is sent.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to which the Kafka message belongs to.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Metadata

Metadata of the Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Record Attributes

Attributes of the Kafka record.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Creation Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of record creation.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Map of HTTP headers in the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Keys of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Leader Epoch</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Leader epoch of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Log Append Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Log append timestamp of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Keystore

Configures the keystore for the TLS protocol. The keystore you generate contains a private key and a
public certificate.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the keystore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the key to use when the keystore contains multiple private keys. By default, Mule uses the first key in the file.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the private key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the keystore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Proxy Config Params

Configures the proxy configuration parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Host</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Hostname or IP address of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Port</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Port of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect

Configures a standard reconnection strategy, which specifies how often to reconnect and how many
reconnection attempts the connector source or operation can make.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How many reconnection attempts the Mule app can make.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect Forever

Configures a forever reconnection strategy by which the connector source or operation attempts to
reconnect at a specified frequency for as long as the Mule app runs.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnection

Configures a reconnection strategy for an operation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Fails Deployment</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if, when an app is deployed, a connectivity test does not pass after exhausting the associated reconnection strategy:</p></div><div><ul><li><p><code>true</code></p><div><p>Allow the deployment to fail.</p></div></li><li><p><code>false</code></p><div><p>Ignore the results of the connectivity test.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Reconnection strategy to use.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Record

Type for records.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td><td><div><div><p>Kafka record attributes.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload for the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Redelivery Policy

Configures the redelivery policy for executing requests that generate errors. You can add a
redelivery policy to any source in a flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Redelivery Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of times that a redelivered request can be processed unsuccessfully before returning a REDELIVERY_EXHAUSTED error.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Secure Hash</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule uses a secure hash algorithm to identify a redelivered message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message Digest Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Secure hashing algorithm to use if the <strong>Use Secure Hash</strong> field is <code>true</code>. If the payload of the message is a Java object, Mule ignores this value and returns the value that the payload’s <code>hashCode()</code> returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Id Expression</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if <strong>Use Secure Hash</strong> is <code>false</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Object Store</strong></p></td><td><div><div><p>ObjectStore</p></div></div></td><td><div><div><p>Configures the object store that stores the redelivery counter for each message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable File Store Stream

Configures the repeatable file-store streaming strategy by which Mule keeps a portion of the stream
content in memory. If the stream content is larger than the configured buffer size, Mule backs up
the buffer’s content to disk and then clears the memory.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>In Memory Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory that the stream can use for data. If the amount of memory exceeds this value, Mule buffers the content to disk. To optimize performance:</p></div><div><ul><li><p>Configure a larger buffer size to avoid the number of times Mule needs to write the buffer on disk. This increases performance, but it also limits the number of concurrent requests your application can process, because it requires additional memory.</p></li><li><p>Configure a smaller buffer size to decrease memory load at the expense of response time.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>In Memory Size</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable In Memory Stream

Configures the in-memory streaming strategy by which the request fails if the data exceeds the MAX
buffer size. Always run performance tests to find the optimal buffer size for your specific use
case.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Initial Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Initial amount of memory to allocate to the data stream. If the streamed data exceeds this value, the buffer expands by <strong>Buffer Size Increment</strong>, with an upper limit of <strong>Max In Memory Size value</strong>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Size Increment</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount by which the buffer size expands if it exceeds its initial size. Setting a value of <code>0</code> or lower specifies that the buffer can’t expand.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory to use. If more than that is used then a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised. A value lower than or equal to zero means no limit.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>Initial Buffer Size</strong>, <strong>Buffer Size Increment</strong>, and <strong>Buffer Unit</strong> fields.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Standard Revocation Check

Configures standard revocation checks for TLS certificates.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Only End Entities</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Which elements to verify in the certificate chain:</p></div><div><ul><li><p><code>true</code></p><div><p>Verify only the last element in the certificate chain.</p></div></li><li><p><code>false</code></p><div><p>Verify all elements in the certificate chain.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Prefer Crls</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>How to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Check the Certification Revocation List (CRL) for certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Use the Online Certificate Status Protocol (OCSP) to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>No Fallback</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to use the secondary method to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Use the method that wasn’t specified in the <strong>Prefer Crls</strong> field (the secondary method) to check certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Do not use the secondary method to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Soft Fail</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if the revocation server can’t be reached or is busy:</p></div><div><ul><li><p><code>true</code></p><div><p>Avoid verification failure.</p></div></li><li><p><code>false</code></p><div><p>Allow the verification to fail.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Tcp Client Socket Params

Configures the TCP client socket parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Send Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer (in bytes) used when sending data, set on the socket itself.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Receive Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Buffer size.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_TIMEOUT</code> value on sockets. Indicates the amount of time (in milliseconds) that the socket waits in a blocking operation before failing. A value of 0 (the default) means waiting indefinitely.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Send Tcp No Delay</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If set, data is sent immediately rather than being collected for efficiency, prioritizing latency over network traffic reduction. Despite the socket default being false, this option defaults to true because reducing network traffic is generally not a major concern.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_LINGER</code> value in milliseconds. This determines how long the socket remains open to ensure all remaining data is transmitted correctly before closing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Keep Alive</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Enables the <code>SO_KEEPALIVE</code> behavior on open sockets. This option periodically checks idle socket connections and closes them if they become unavailable. It is used by server sockets to control whether connections are kept alive before being recycled.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How long the connector waits before timing out when establishing a connection to the remote service.</p></div></div></td><td><div><div><p><code>30000</code></p></div></div></td><td><div></div></td></tr></tbody></table>

### TLS

Configures TLS to provide secure communications for the Mule app.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Enabled Protocols</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of protocols enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Enabled Cipher Suites</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of cipher suites enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Trust Store</strong></p></td><td><div><div><p><a href="#TrustStore">Truststore</a></p></div></div></td><td><div><div><p>Configures the TLS truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Store</strong></p></td><td><div><div><p><a href="#KeyStore">Keystore</a></p></div></div></td><td><div><div><p>Configures the TLS keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Revocation Check</strong></p></td><td><div><div><ul><li><p><a href="#StandardRevocationCheck">Standard Revocation Check</a></p></li><li><p><a href="#CustomOcspResponder">Custom OCSP Responder</a></p></li><li><p><a href="#CrlFile">CRL File</a></p></li></ul></div></div></td><td><div><div><p>Configures a revocation checking mechanism.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Topic Partition

Type for topic partition.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of partitions.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

### Truststore

Configures the truststore for TLS.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the truststore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the truststore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Insecure</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule stops performing certificate validations. Setting this to <code>true</code> can make connections vulnerable to attacks.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=7d20555e45569f35d331caa7b323729adce6375013dcabf7947a64217af04cc6 url=/mulesoft/current/en-us/kafka-connector/4.11/index.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Apache Kafka Connector 4.11

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system and achieve seamless integration between your Mule app and a Kafka cluster,
using Mule runtime engine (Mule).

For compatibility information, see the Apache Kafka Connector Release Notes.

## Before You Begin

Before creating an app, you must:

- Have access to the Apache Kafka target resource and Anypoint Platform

- Understand how to create a Mule app using Anypoint Studio

- Have access to Apache Kafka to get values for the fields that appear in Studio

## Common Use Cases for the Connector

Common use cases for Apache Kafka Connector include:

- **Log Aggregation**

  Leverage the low-latency processing from Apache Kafka to collect logs from multiple services and
  make them available in a standard format to multiple consumers. For example, you can publish a
  message to Apache Kafka and then retrieve it.

- **Analysis and Metrics**

  Optimize your advertising budget by integrating Apache Kafka and your big data analytics solution
  to analyze end user activity, such as page views, clicks, shares, and so on, to serve relevant
  ads. For example, a department store can use a website activity tracker to improve the online
  shopping experience. The gathered data is sent to multiple departments for various computations.
  Each department reviews the received information to stay informed about what the customer is
  looking for and then provides recommendations accordingly.

- **Notifications and Alerts**

  Notify customers about various financial events, such as the recent amount of a transaction or
  more complex events like future investment suggestions based on integrations with credit agencies,
  location, and so on.

- **Time-Sensitive Applications**

  Build integration applications that are time-sensitive. For example, you can build an application
  that ensures that patients in a hospital receive the care they need in a timely manner with a
  hospital server that processes emergency requests for patient admissions and orders the requests
  based on priority determined by specified criteria. In this scenario, an application processes
  Apache Kafka messages in the order that they are received, relying on the order and idempotency of
  the messages sent through the queue. For example, a newsroom can use the Apache Kafka system to
  deliver the latest news. Retrieve the latest news by building an integration application by
  reading from the end of the Apache Kafka queue first.

For examples of these use cases, refer to
[Apache Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-examples).

### Publish-to Use Cases

With Kafka Connector, applications can publish binary messages to the Kafka server. Some examples of
use cases include:

- Publishing binary data to the Kafka server and the underlying topic.

- Setting the batch size of the data to publish to Kafka when working with large volumes of data.

  - To optimize for performance, companies can batch messages to send. Kafka stores the message
    until the batch size is reached and completes the send at that time.

- Configuring the message size to send to focus on optimal performance.

  - Kafka is not intended to process and handle large messages. Messages are typically in the 1 MB
    range and users set the size to avoid performance degradation. In the case of an error, the
    message is rejected.

- Blocking further commits on a configurable level of acknowledgment for the messages published to
  the Kafka server to ensure successful data transmission.

  - Acknowledgments enable users to ensure that the message is sent prior to publishing more
    messages. This is specifically useful in time-ordered or event-ordered messages, such as logs or
    patient drug administration orders. Ensuring that messages are sent in order helps the
    downstream application process the messages in the right order.

- Configuring how data is serialized during a publish.

- Securing messages sent during Mutual TLS.

The following lists the acceptance criteria for publishing:

- Publish a message to a Kafka topic.

- Configure the batch size and size of the message.

- Obtain an acknowledgment once publishing is complete at the configured level.

- Send the message securely via Mutual TLS.

- Configure the serialization type.

### Subscribe-from Use Cases

With Kafka Connector, applications can obtain messages from Kafka for further consumption
downstream. Some examples of use cases include:

Reading from Kafka:

- Subscribing to the Kafka server and the underlying group to read and consume messages for
  downstream processing.

- Subscribing to a specific Kafka partition to process messages.

  - Users with a high availability microservice don’t want to rely on Kafka’s rebalancing in the
    event of a failure.

  - If users have a local state associated with their partition, they want to process only that
    partition.

- Configuring the offset value to a set value or to the beginning or end of the topic.

  - Users have a local store and want to use that information to start processing their records.

  - Users have time-sensitive records and want to skip to the end if the application must be
    up-to-date or skip to the beginning if it is a new application processing the records.

- Reading the offset value from an alternate storage system on restart.

  - Users have a local store with the offset information and want to read the value from their local
    storage.

- Setting the interval for which to block the receipt of messages for varying downstream processing
  intervals.

Processing the messages:

- Ensuring there is no data loss when the downstream application crashes by manually configuring
  commits to have more control.

- Storing a commit value in a local store or in the Kafka storage and blocking until the store is
  successful.

- Storing an offset asynchronously in a local store or in the Kafka storage.

- Using Kafka’s in-built capability of load-balancing with multiple applications reading from the
  same group ID.

- Configuring the number of records to process in a single call.

The following lists the acceptance criteria for subscribing:

- Read a message from Kafka from a specific partition or topic.

- Read a message from Kafka after obtaining the offset from a local store.

- Read a message from the beginning of the queue, the end of the queue, and a pre-specified offset.

- Ensure a high level of performance when there is one consumer per thread. Multiple consumers exist
  in a single group.

## Audience

- Starting user

  To create a Mule app, see [Apache Kafka Studio Configuration](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-studio).

- Power user

  Read [XML and Maven Support](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-xml-maven) and [Examples](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-examples).

## Next

After you complete the prerequisites, you are ready to create an app with
[Anypoint Studio](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-studio).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange)

- [Apache Kafka Connector](https://www.mulesoft.com/exchange/com.mulesoft.connectors/mule-kafka-connector/)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=fd49aa58b5ba4cd5b205d634cd7aa35270cb7f98768a7fcf24089fa5acfa3f30 url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-config-topics.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Apache Kafka Connector 4.11 - Additional Configuration Information

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Set additional configuration for Anypoint Connector for Apache Kafka (Apache Kafka Connector).

## Configure a Custom Partitioner

You can configure a custom partitioner for Apache Kafka Connector in a Mule app:

1.  Use Maven to create a Java project and add the custom partitioner to it:

    ```java
    public class CustomPartitioner implements Partitioner {
    // Implementation
    }
    ```

2.  Add this dependency in the Mule app:

    ```java
    <dependencies>
     <dependency>
       <groupId>org.example</groupId>
       <artifactId>custom-partitioner</artifactId>
       <version>1.0-SNAPSHOT</version>
     </dependency>
    </dependencies>
    ```

3.  Add this dependency to `additionalPluginDependencies`:

    ```java
    <plugin>
     <groupId>org.mule.tools.maven</groupId>
     <artifactId>mule-maven-plugin</artifactId>
     <version>${mule.maven.plugin.version}</version>
     <extensions>true</extensions>
     <configuration>
      <additionalPluginDependencies>
      <plugin>
       <groupId>com.mulesoft.connectors</groupId>
       <artifactId>mule-kafka-connector</artifactId>
        <additionalDependencies>
         <dependency>
          <groupId>io.confluent</groupId>
          <artifactId>kafka-avro-serializer</artifactId>
          <version>7.6.1</version>
         </dependency>
         <dependency>
          <groupId>org.example</groupId>
          <artifactId>custom-partitioner</artifactId>
          <version>1.0-SNAPSHOT</version>
         </dependency>
        </additionalDependencies>
       </plugin>
       </additionalPluginDependencies>
       <classifier>mule-application</classifier>
     </configuration>
    </plugin>
    ```

4.  Add the custom partitioner to the producer configuration:

    ```java
    <kafka:producer-config name="Apache_Kafka_Producer_configuration"
        doc:name="Apache Kafka Producer configuration"
        doc:id="cb9de3c5-d6d2-4f9b-a255-75a9985bffb7">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="<kafka-url>" />
            </kafka:bootstrap-servers>
            <kafka:additional-properties>
                <kafka:additional-property key="key.serializer"
                    value="org.apache.kafka.common.serialization.StringSerializer" />
                <kafka:additional-property key="value.serializer"
                    value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer" />
                <kafka:additional-property key="schema.registry.url"
                    value="<schema-registry-url>" />
                <kafka:additional-property key="basic.auth.credentials.source"
                    value="USER_INFO" />
                <kafka:additional-property key="basic.auth.user.info"
                    value="user:pass" />
                <kafka:additional-property key="auto.register.schemas"
                    value="true" />
                <kafka:additional-property key="value.subject.name.strategy"
                    value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
                <kafka:additional-property key="partitioner.class"
                    value="org.example.CustomPartitioner" />
            </kafka:additional-properties>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>
    ```

## Next Step

After you complete configuring the connector, you can try the [examples](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=2d7e16a1a43fc9ed2d56104c580676f8b6edf52e0d1763b4648d5e3214e9cfa4 url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-reference.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Apache Kafka Connector 4.11 Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system. It provides seamless integration between your Mule app and an Apache Kafka
cluster, using Mule runtime engine (Mule).

> [!NOTE] When a **Message Listener** or a **Batch Message Listener** uses the `MANUAL`
> acknowledgement mode, you must use a **Commit** operation at the end of the flow when the flow
> finishes successfully (either because there were no errors or because there is an **On Error
> Continue** component in the flow).

> [!NOTE] Mule server notifications are not supported because the Kafka library used in the
> connector manages network disruptions internally.

## Consumer Configuration

Configuration for consumers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#consumer-plaintext">Consumer Plaintext Connection</a></p></li><li><p><a href="#consumer-sasl-kerberos">Consumer Kerberos Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-oauth-bearer-cc-connection">Consumer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#consumer-sasl-scram">Consumer SASL/SCRAM Connection</a></p></li><li><p><a href="#consumer-sasl-plain">Consumer SASL/PLAIN Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-token-connection">Consumer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>AUTO</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait to perform a poll if data is not available in the buffer (fetched). If no value is set, the poll is returned immediately with any records that are currently available in the buffer or else returns empty if there is no data. Must not be negative.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default listener poll timeout</strong> field. This combines with <strong>Poll Timeout</strong> to define the total timeout for the polling.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait for an operation to finish. If no value is set or a negative value is set, the operation waits forever.</p></div></div></td><td><div><div><p><code>-1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default operation timeout</strong> field. This combines with <strong>Operation Timeout</strong> to define the total default timeout for the operations that use this configuration.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely. Additionally, the
connector supports only
[RFC6749 standard](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3).

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default Group ID for all the Kafka Consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p>READ_UNCOMMITTED</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether internal topics matching a subscribed pattern is excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the reconnect backoff timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. You can override this field at the source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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 parameter can be overridden at source level.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum number of records returned on a poll call to the Kafka cluster. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 session.timeout.ms, 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 rebalances.</p></div></div></td><td><div><div><p>3</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch heartbeat interval time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 group.min.session.timeout.ms and group.max.session.timeout.ms.</p></div></div></td><td><div><div><p>10</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for session timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for connections maximum idle time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>The list of subscription regular expressions to subscribe to. This topics will be automatically rebalanced between the amount of consumers of the topic.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>The list of topic-partition pairs to assign. Note that there will be no automatic rebalance of the consumers</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The minimum amount of data the server should return for a fetch request. If insufficient data is available the request waits 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 data to accumulate which can improve server throughput a bit at the cost of some additional latency. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div></div></td><td><div><div><p>BYTE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 an absolute maximum. The maximum record batch size accepted by the broker is defined via message.max.bytes (broker config) or max.message.bytes (topic config). Note that the consumer performs multiple fetches in parallel. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 message.max.bytes (broker config) or max.message.bytes (topic config). See fetch.max.bytes for limiting the consumer request size.This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch maximum wait timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>User used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

---

## Producer Configuration

Configuration for producers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#producer-plaintext">Producer Plaintext Connection</a></p></li><li><p><a href="#producer-sasl-kerberos">Producer Kerberos Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-oauth-bearer-cc-connection">Producer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#producer-sasl-scram">Producer SASL/SCRAM Connection</a></p></li><li><p><a href="#producer-sasl-plain">Producer SASL/PLAIN Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-token-connection">Producer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default topic name to use by the producer operations, overridable at the operation’s configuration level.</p></div></div></td><td><div><div><p><code>defaultTopicName</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names..</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The producer attempts 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. No attempt will be made to batch records larger than this size. Requests sent to brokers will contain multiple batches, one for each partition with data available to be sent. A small batch size will make batching less common and may reduce throughput (a batch size of zero will disable batching entirely). A very large batch size may use memory a bit more wastefully as we will always allocate a buffer of the specified batch size in anticipation of additional records.</p></div></div></td><td><div><div><p>16</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the batch size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.block.ms after which it will throw an exception. 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 used for compression (if compression is enabled) as well as for maintaining in-flight requests. The default value in the Kafka docs is of 33554432 (32MB), but this should be capped to align with expected values for mule instances in cloudhub (v0.1 core)</p></div></div></td><td><div><div><p>1000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are none, gzip, snappy, lz4, or zstd. Compression is of full batches of data, so the efficacy of batching will also impact the compression ratio (more batching means better compression).</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the value specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the connections maximum idle scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>An upper bound on the time to report success or failure after a call to send() returns. This limits the total time that a record will be delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retriable send failures. The producer may report failure to send a record earlier than this config if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch which reached an earlier delivery expiration deadline. The value of this config should be greater than or equal to the sum of request.timeout.ms and linger.ms.</p></div></div></td><td><div><div><p>120</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the delivery timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection to be less than or equal to 5, retries to be greater than 0 and acks must be 'all'. If these values are not explicitly set by the user, suitable values will be chosen. If incompatible values are set, a ConnectionException will be thrown</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 waits for up to the given delay to allow other records to be sent so that the sends can be batched together. This can be thought of as analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching: once we get batch.size worth of records for a partition it is sent immediately regardless of this setting, however if we have fewer than this many bytes accumulated for this partition we will 'linger' for the specified time waiting for more records to show up. This setting defaults to 0 (i.e. no delay). Setting linger.ms=5, for example, would have the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p>0</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the linger time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls how long KafkaProducer.send() and KafkaProducer.partitionsFor() 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.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the maximum block time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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).</p></div></div></td><td><div><div><p>5</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer acknowledge mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>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</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection 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 second succeeds, then the records in the second batch may appear first. Note additionally that produce requests will be failed before the number of retries has been exhausted if the timeout configured by delivery.timeout.ms expires first before successful acknowledgment. Users should generally prefer to leave this config unset and instead use delivery.timeout.ms to control retry behavior.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the retry backoff timeout time scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry backoff timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the request timeout time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>The configuration controls which partitioning strategy is used when sending messages without providing a key or a partition.</p></div></div></td><td><div><div><p>DEFAULT</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>EncryptionType</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Consumer Sources

- [Batch Message Listener](#batch-message-listener)

- [Message Listener](#message-listener)

### Batch Message Listener

`<kafka:batch-message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a list of messages
to the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#Record">Record</a></p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#ConsumerContext">Consumer Context</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

> [!NOTE] The **Batch Message Listener** source does not support configurable streaming strategies
> because the source takes a batch of records as an input stream. The streaming strategy
> configuration is non-repeatable-stream by default for the source.

### Message Listener

`<kafka:message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a single message to
the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

## Consumer Operations

- [Commit](#commit)

- [Consume](#consume)

- [Seek](#seek)

### Commit

`<kafka:commit>`

Commits the offsets associated to a message or batch of messages consumed in a **Message Listener**.
This is a list or a single message consumed in the **Batch Message Listener** source.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumer commit key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Commit key of the last poll. This operation is valid only when used inside a flow that uses one of the sources (<strong>Batch Message Listener</strong> or <strong>Message Listener</strong>) which inserts this value as an attribute in the Mule event.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_ACK\_MODE

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ALREADY\_COMMITTED

- KAFKA:TIMEOUT

- KAFKA:SESSION\_NOT\_FOUND

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Consume

`<kafka:consume>`

Receives messages from one or more Kafka topics. This operation works similarly to the **Message
Listener** source, so all the operations that apply to that, apply to this operation as well.

> [!NOTE] The **Consume** operation does not return the `consumerCommitKey`.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Consumption timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>IMMEDIATE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ILLEGAL\_STATE

- KAFKA:TIMEOUT

- KAFKA:SERIALIZATION\_ERROR

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Seek

`<kafka:seek>`

Sets the current offset of the consumer for the given topic and partition to the provided offset
value.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which the <strong>Seek</strong> operation is performed.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number that has its offset modified.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:INVALID\_TOPIC

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

## Producer Operations

- [Bulk Publish](#bulkPublish)

- [Publish](#publish)

### Bulk Publish

`<kafka:bulk-publish>`

Publishes a bulk of messages to the specified Kafka topic, optionally specifying the partition, key,
and message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of <a href="#KafkaMessage">Kafka Message</a></p></div></div></td><td><div><div><p>List of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:AUTHENTICATION\_ERROR

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

### Publish

`<kafka:publish>`

Publishes a message to the specified Kafka topic, optionally specifying the partition, key, and
message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) Topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p><a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

## Object Types

- [Consumer Context](#ConsumerContext)

- [CRL File](#CrlFile)

- [Custom OCSP Responder](#CustomOcspResponder)

- [Expiration Policy](#ExpirationPolicy)

- [Kafka Message](#KafkaMessage)

- [Kafka Message Attributes](#KafkaMessageAttributes)

- [Kafka Message Metadata](#KafkaMessageMetadata)

- [Kafka Record Attributes](#KafkaRecordAttributes)

- [Keystore](#KeyStore)

- [Proxy Config Params](#ProxyConfigParams)

- [Reconnect](#Reconnect)

- [Reconnect Forever](#Reconnect-Forever)

- [Reconnection](#Reconnection)

- [Record](#Record)

- [Redelivery Policy](#RedeliveryPolicy)

- [Repeatable File Store Stream](#RepeatableFileStoreStream)

- [Repeatable In Memory Stream](#RepeatableInMemoryStream)

- [Standard Revocation Check](#StandardRevocationCheck)

- [Tcp Client Socket Params](#TcpClientSocketParams)

- [TLS](#Tls)

- [Topic Partition](#TopicPartition)

- [Truststore](#TrustStore)

### Consumer Context

Type for the consumer context.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### CRL File

Specifies the location of the certification revocation list (CRL) file.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the CRL file.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Custom OCSP Responder

Configures a custom OCSP responder for certification revocation checks.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Url</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>URL of the OCSP responder.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Cert Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the signing certificate for the OCSP response. If specified, the alias must be in the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Expiration Policy

Configures an expiration policy strategy.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Idle Time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Configures the maximum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Max Idle Time</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message

Represents a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaMessageAttributes">Kafka Message Attributes</a></p></div></div></td><td><div><div><p>Attributes associated with the Kafka message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Attributes

Represents the attributes of a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Headers of the Kafka message, represented as a map in which the key is a string and the value is an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Key of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the topic where the Kafka message is sent.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to which the Kafka message belongs to.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Metadata

Metadata of the Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Record Attributes

Attributes of the Kafka record.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Creation Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of record creation.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Map of HTTP headers in the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Keys of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Leader Epoch</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Leader epoch of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Log Append Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Log append timestamp of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Keystore

Configures the keystore for the TLS protocol. The keystore you generate contains a private key and a
public certificate.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the keystore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the key to use when the keystore contains multiple private keys. By default, Mule uses the first key in the file.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the private key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the keystore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Proxy Config Params

Configures the proxy configuration parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Host</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Hostname or IP address of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Port</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Port of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect

Configures a standard reconnection strategy, which specifies how often to reconnect and how many
reconnection attempts the connector source or operation can make.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How many reconnection attempts the Mule app can make.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect Forever

Configures a forever reconnection strategy by which the connector source or operation attempts to
reconnect at a specified frequency for as long as the Mule app runs.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnection

Configures a reconnection strategy for an operation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Fails Deployment</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if, when an app is deployed, a connectivity test does not pass after exhausting the associated reconnection strategy:</p></div><div><ul><li><p><code>true</code></p><div><p>Allow the deployment to fail.</p></div></li><li><p><code>false</code></p><div><p>Ignore the results of the connectivity test.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Reconnection strategy to use.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Record

Type for records.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td><td><div><div><p>Kafka record attributes.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload for the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Redelivery Policy

Configures the redelivery policy for executing requests that generate errors. You can add a
redelivery policy to any source in a flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Redelivery Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of times that a redelivered request can be processed unsuccessfully before returning a REDELIVERY_EXHAUSTED error.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Secure Hash</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule uses a secure hash algorithm to identify a redelivered message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message Digest Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Secure hashing algorithm to use if the <strong>Use Secure Hash</strong> field is <code>true</code>. If the payload of the message is a Java object, Mule ignores this value and returns the value that the payload’s <code>hashCode()</code> returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Id Expression</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if <strong>Use Secure Hash</strong> is <code>false</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Object Store</strong></p></td><td><div><div><p>ObjectStore</p></div></div></td><td><div><div><p>Configures the object store that stores the redelivery counter for each message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable File Store Stream

Configures the repeatable file-store streaming strategy by which Mule keeps a portion of the stream
content in memory. If the stream content is larger than the configured buffer size, Mule backs up
the buffer’s content to disk and then clears the memory.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>In Memory Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory that the stream can use for data. If the amount of memory exceeds this value, Mule buffers the content to disk. To optimize performance:</p></div><div><ul><li><p>Configure a larger buffer size to avoid the number of times Mule needs to write the buffer on disk. This increases performance, but it also limits the number of concurrent requests your application can process, because it requires additional memory.</p></li><li><p>Configure a smaller buffer size to decrease memory load at the expense of response time.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>In Memory Size</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable In Memory Stream

Configures the in-memory streaming strategy by which the request fails if the data exceeds the MAX
buffer size. Always run performance tests to find the optimal buffer size for your specific use
case.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Initial Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Initial amount of memory to allocate to the data stream. If the streamed data exceeds this value, the buffer expands by <strong>Buffer Size Increment</strong>, with an upper limit of <strong>Max In Memory Size value</strong>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Size Increment</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount by which the buffer size expands if it exceeds its initial size. Setting a value of <code>0</code> or lower specifies that the buffer can’t expand.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory to use. If more than that is used then a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised. A value lower than or equal to zero means no limit.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>Initial Buffer Size</strong>, <strong>Buffer Size Increment</strong>, and <strong>Buffer Unit</strong> fields.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Standard Revocation Check

Configures standard revocation checks for TLS certificates.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Only End Entities</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Which elements to verify in the certificate chain:</p></div><div><ul><li><p><code>true</code></p><div><p>Verify only the last element in the certificate chain.</p></div></li><li><p><code>false</code></p><div><p>Verify all elements in the certificate chain.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Prefer Crls</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>How to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Check the Certification Revocation List (CRL) for certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Use the Online Certificate Status Protocol (OCSP) to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>No Fallback</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to use the secondary method to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Use the method that wasn’t specified in the <strong>Prefer Crls</strong> field (the secondary method) to check certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Do not use the secondary method to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Soft Fail</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if the revocation server can’t be reached or is busy:</p></div><div><ul><li><p><code>true</code></p><div><p>Avoid verification failure.</p></div></li><li><p><code>false</code></p><div><p>Allow the verification to fail.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Tcp Client Socket Params

Configures the TCP client socket parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Send Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer (in bytes) used when sending data, set on the socket itself.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Receive Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Buffer size.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_TIMEOUT</code> value on sockets. Indicates the amount of time (in milliseconds) that the socket waits in a blocking operation before failing. A value of 0 (the default) means waiting indefinitely.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Send Tcp No Delay</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If set, data is sent immediately rather than being collected for efficiency, prioritizing latency over network traffic reduction. Despite the socket default being false, this option defaults to true because reducing network traffic is generally not a major concern.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_LINGER</code> value in milliseconds. This determines how long the socket remains open to ensure all remaining data is transmitted correctly before closing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Keep Alive</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Enables the <code>SO_KEEPALIVE</code> behavior on open sockets. This option periodically checks idle socket connections and closes them if they become unavailable. It is used by server sockets to control whether connections are kept alive before being recycled.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How long the connector waits before timing out when establishing a connection to the remote service.</p></div></div></td><td><div><div><p><code>30000</code></p></div></div></td><td><div></div></td></tr></tbody></table>

### TLS

Configures TLS to provide secure communications for the Mule app.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Enabled Protocols</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of protocols enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Enabled Cipher Suites</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of cipher suites enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Trust Store</strong></p></td><td><div><div><p><a href="#TrustStore">Truststore</a></p></div></div></td><td><div><div><p>Configures the TLS truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Store</strong></p></td><td><div><div><p><a href="#KeyStore">Keystore</a></p></div></div></td><td><div><div><p>Configures the TLS keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Revocation Check</strong></p></td><td><div><div><ul><li><p><a href="#StandardRevocationCheck">Standard Revocation Check</a></p></li><li><p><a href="#CustomOcspResponder">Custom OCSP Responder</a></p></li><li><p><a href="#CrlFile">CRL File</a></p></li></ul></div></div></td><td><div><div><p>Configures a revocation checking mechanism.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Topic Partition

Type for topic partition.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of partitions.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

### Truststore

Configures the truststore for TLS.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the truststore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the truststore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Insecure</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule stops performing certificate validations. Setting this to <code>true</code> can make connections vulnerable to attacks.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=22982e46e38d2e3b26113b185d2d2d3d5346bc4350daece0be7ce1c330bf0638 url=/mulesoft/current/en-us/kafka-connector/4.12/index.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Apache Kafka Connector 4.12

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system and achieve seamless integration between your Mule app and a Kafka cluster,
using Mule runtime engine (Mule).

For compatibility information, see the Apache Kafka Connector Release Notes.

## Before You Begin

Before creating an app, you must:

- Have access to the Apache Kafka target resource and Anypoint Platform

- Understand how to create a Mule app using Anypoint Studio

- Have access to Apache Kafka to get values for the fields that appear in Studio

## Common Use Cases for the Connector

Common use cases for Apache Kafka Connector include:

- **Log Aggregation**

  Leverage the low-latency processing from Apache Kafka to collect logs from multiple services and
  make them available in a standard format to multiple consumers. For example, you can publish a
  message to Apache Kafka and then retrieve it.

- **Analysis and Metrics**

  Optimize your advertising budget by integrating Apache Kafka and your big data analytics solution
  to analyze end user activity, such as page views, clicks, shares, and so on, to serve relevant
  ads. For example, a department store can use a website activity tracker to improve the online
  shopping experience. The gathered data is sent to multiple departments for various computations.
  Each department reviews the received information to stay informed about what the customer is
  looking for and then provides recommendations accordingly.

- **Notifications and Alerts**

  Notify customers about various financial events, such as the recent amount of a transaction or
  more complex events like future investment suggestions based on integrations with credit agencies,
  location, and so on.

- **Time-Sensitive Applications**

  Build integration applications that are time-sensitive. For example, you can build an application
  that ensures that patients in a hospital receive the care they need in a timely manner with a
  hospital server that processes emergency requests for patient admissions and orders the requests
  based on priority determined by specified criteria. In this scenario, an application processes
  Apache Kafka messages in the order that they are received, relying on the order and idempotency of
  the messages sent through the queue. For example, a newsroom can use the Apache Kafka system to
  deliver the latest news. Retrieve the latest news by building an integration application by
  reading from the end of the Apache Kafka queue first.

For examples of these use cases, refer to
[Apache Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-examples).

### Publish-to Use Cases

With Kafka Connector, applications can publish binary messages to the Kafka server. Some examples of
use cases include:

- Publishing binary data to the Kafka server and the underlying topic.

- Setting the batch size of the data to publish to Kafka when working with large volumes of data.

  - To optimize for performance, companies can batch messages to send. Kafka stores the message
    until the batch size is reached and completes the send at that time.

- Configuring the message size to send to focus on optimal performance.

  - Kafka is not intended to process and handle large messages. Messages are typically in the 1 MB
    range and users set the size to avoid performance degradation. In the case of an error, the
    message is rejected.

- Blocking further commits on a configurable level of acknowledgment for the messages published to
  the Kafka server to ensure successful data transmission.

  - Acknowledgments enable users to ensure that the message is sent prior to publishing more
    messages. This is specifically useful in time-ordered or event-ordered messages, such as logs or
    patient drug administration orders. Ensuring that messages are sent in order helps the
    downstream application process the messages in the right order.

- Configuring how data is serialized during a publish.

- Securing messages sent during Mutual TLS.

The following lists the acceptance criteria for publishing:

- Publish a message to a Kafka topic.

- Configure the batch size and size of the message.

- Obtain an acknowledgment once publishing is complete at the configured level.

- Send the message securely via Mutual TLS.

- Configure the serialization type.

### Subscribe-from Use Cases

With Kafka Connector, applications can obtain messages from Kafka for further consumption
downstream. Some examples of use cases include:

Reading from Kafka:

- Subscribing to the Kafka server and the underlying group to read and consume messages for
  downstream processing.

- Subscribing to a specific Kafka partition to process messages.

  - Users with a high availability microservice don’t want to rely on Kafka’s rebalancing in the
    event of a failure.

  - If users have a local state associated with their partition, they want to process only that
    partition.

- Configuring the offset value to a set value or to the beginning or end of the topic.

  - Users have a local store and want to use that information to start processing their records.

  - Users have time-sensitive records and want to skip to the end if the application must be
    up-to-date or skip to the beginning if it is a new application processing the records.

- Reading the offset value from an alternate storage system on restart.

  - Users have a local store with the offset information and want to read the value from their local
    storage.

- Setting the interval for which to block the receipt of messages for varying downstream processing
  intervals.

Processing the messages:

- Ensuring there is no data loss when the downstream application crashes by manually configuring
  commits to have more control.

- Storing a commit value in a local store or in the Kafka storage and blocking until the store is
  successful.

- Storing an offset asynchronously in a local store or in the Kafka storage.

- Using Kafka’s in-built capability of load-balancing with multiple applications reading from the
  same group ID.

- Configuring the number of records to process in a single call.

The following lists the acceptance criteria for subscribing:

- Read a message from Kafka from a specific partition or topic.

- Read a message from Kafka after obtaining the offset from a local store.

- Read a message from the beginning of the queue, the end of the queue, and a pre-specified offset.

- Ensure a high level of performance when there is one consumer per thread. Multiple consumers exist
  in a single group.

## Audience

- Starting user

  To create a Mule app, see [Apache Kafka Studio Configuration](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-studio).

- Power user

  Read [XML and Maven Support](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-xml-maven) and [Examples](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-examples).

## Next

After you complete the prerequisites, you are ready to create an app with
[Anypoint Studio](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-studio).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange)

- [Apache Kafka Connector](https://www.mulesoft.com/exchange/com.mulesoft.connectors/mule-kafka-connector/)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=03074d27af5630a505388ae85841d18930db36570a834f58a78cb8ea1158d70b url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-config-topics.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Apache Kafka Connector 4.12 - Additional Configuration Information

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Set additional configuration for Anypoint Connector for Apache Kafka (Apache Kafka Connector).

## Configure a Custom Partitioner

You can configure a custom partitioner for Apache Kafka Connector in a Mule app:

1.  Use Maven to create a Java project and add the custom partitioner to it:

    ```java
    public class CustomPartitioner implements Partitioner {
    // Implementation
    }
    ```

2.  Add this dependency in the Mule app:

    ```java
    <dependencies>
     <dependency>
       <groupId>org.example</groupId>
       <artifactId>custom-partitioner</artifactId>
       <version>1.0-SNAPSHOT</version>
     </dependency>
    </dependencies>
    ```

3.  Add this dependency to `additionalPluginDependencies`:

    ```java
    <plugin>
     <groupId>org.mule.tools.maven</groupId>
     <artifactId>mule-maven-plugin</artifactId>
     <version>${mule.maven.plugin.version}</version>
     <extensions>true</extensions>
     <configuration>
      <additionalPluginDependencies>
      <plugin>
       <groupId>com.mulesoft.connectors</groupId>
       <artifactId>mule-kafka-connector</artifactId>
        <additionalDependencies>
         <dependency>
          <groupId>io.confluent</groupId>
          <artifactId>kafka-avro-serializer</artifactId>
          <version>7.6.1</version>
         </dependency>
         <dependency>
          <groupId>org.example</groupId>
          <artifactId>custom-partitioner</artifactId>
          <version>1.0-SNAPSHOT</version>
         </dependency>
        </additionalDependencies>
       </plugin>
       </additionalPluginDependencies>
       <classifier>mule-application</classifier>
     </configuration>
    </plugin>
    ```

4.  Add the custom partitioner to the producer configuration:

    ```java
    <kafka:producer-config name="Apache_Kafka_Producer_configuration"
        doc:name="Apache Kafka Producer configuration"
        doc:id="cb9de3c5-d6d2-4f9b-a255-75a9985bffb7">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="<kafka-url>" />
            </kafka:bootstrap-servers>
            <kafka:additional-properties>
                <kafka:additional-property key="key.serializer"
                    value="org.apache.kafka.common.serialization.StringSerializer" />
                <kafka:additional-property key="value.serializer"
                    value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer" />
                <kafka:additional-property key="schema.registry.url"
                    value="<schema-registry-url>" />
                <kafka:additional-property key="basic.auth.credentials.source"
                    value="USER_INFO" />
                <kafka:additional-property key="basic.auth.user.info"
                    value="user:pass" />
                <kafka:additional-property key="auto.register.schemas"
                    value="true" />
                <kafka:additional-property key="value.subject.name.strategy"
                    value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
                <kafka:additional-property key="partitioner.class"
                    value="org.example.CustomPartitioner" />
            </kafka:additional-properties>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>
    ```

## Next Step

After you complete configuring the connector, you can try the [examples](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=3c2aa3ca7e03ef71a280a16d1b6b62ffffd071eb3285447c78b7d72c57c50a63 url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-reference.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Apache Kafka Connector 4.12 Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system. It provides seamless integration between your Mule app and an Apache Kafka
cluster, using Mule runtime engine (Mule).

> [!NOTE] When a **Message Listener** or a **Batch Message Listener** uses the `MANUAL`
> acknowledgement mode, you must use a **Commit** operation at the end of the flow when the flow
> finishes successfully (either because there were no errors or because there is an **On Error
> Continue** component in the flow).

> [!NOTE] Mule server notifications are not supported because the Kafka library used in the
> connector manages network disruptions internally.

## Consumer Configuration

Configuration for consumers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#consumer-plaintext">Consumer Plaintext Connection</a></p></li><li><p><a href="#consumer-sasl-kerberos">Consumer Kerberos Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-oauth-bearer-cc-connection">Consumer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#consumer-sasl-scram">Consumer SASL/SCRAM Connection</a></p></li><li><p><a href="#consumer-sasl-plain">Consumer SASL/PLAIN Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-token-connection">Consumer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>AUTO</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait to perform a poll if data is not available in the buffer (fetched). If no value is set, the poll is returned immediately with any records that are currently available in the buffer or else returns empty if there is no data. Must not be negative.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default listener poll timeout</strong> field. This combines with <strong>Poll Timeout</strong> to define the total timeout for the polling.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait for an operation to finish. If no value is set or a negative value is set, the operation waits forever.</p></div></div></td><td><div><div><p><code>-1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default operation timeout</strong> field. This combines with <strong>Operation Timeout</strong> to define the total default timeout for the operations that use this configuration.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely. Additionally, the
connector supports only
[RFC6749 standard](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3).

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default Group ID for all the Kafka Consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p>READ_UNCOMMITTED</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether internal topics matching a subscribed pattern is excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the reconnect backoff timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. You can override this field at the source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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 parameter can be overridden at source level.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum number of records returned on a poll call to the Kafka cluster. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 session.timeout.ms, 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 rebalances.</p></div></div></td><td><div><div><p>3</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch heartbeat interval time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 group.min.session.timeout.ms and group.max.session.timeout.ms.</p></div></div></td><td><div><div><p>10</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for session timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for connections maximum idle time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>The list of subscription regular expressions to subscribe to. This topics will be automatically rebalanced between the amount of consumers of the topic.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>The list of topic-partition pairs to assign. Note that there will be no automatic rebalance of the consumers</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The minimum amount of data the server should return for a fetch request. If insufficient data is available the request waits 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 data to accumulate which can improve server throughput a bit at the cost of some additional latency. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div></div></td><td><div><div><p>BYTE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 an absolute maximum. The maximum record batch size accepted by the broker is defined via message.max.bytes (broker config) or max.message.bytes (topic config). Note that the consumer performs multiple fetches in parallel. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 message.max.bytes (broker config) or max.message.bytes (topic config). See fetch.max.bytes for limiting the consumer request size.This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch maximum wait timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>User used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

---

## Producer Configuration

Configuration for producers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#producer-plaintext">Producer Plaintext Connection</a></p></li><li><p><a href="#producer-sasl-kerberos">Producer Kerberos Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-oauth-bearer-cc-connection">Producer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#producer-sasl-scram">Producer SASL/SCRAM Connection</a></p></li><li><p><a href="#producer-sasl-plain">Producer SASL/PLAIN Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-token-connection">Producer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default topic name to use by the producer operations, overridable at the operation’s configuration level.</p></div></div></td><td><div><div><p><code>defaultTopicName</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names..</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The producer attempts 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. No attempt will be made to batch records larger than this size. Requests sent to brokers will contain multiple batches, one for each partition with data available to be sent. A small batch size will make batching less common and may reduce throughput (a batch size of zero will disable batching entirely). A very large batch size may use memory a bit more wastefully as we will always allocate a buffer of the specified batch size in anticipation of additional records.</p></div></div></td><td><div><div><p>16</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the batch size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.block.ms after which it will throw an exception. 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 used for compression (if compression is enabled) as well as for maintaining in-flight requests. The default value in the Kafka docs is of 33554432 (32MB), but this should be capped to align with expected values for mule instances in cloudhub (v0.1 core)</p></div></div></td><td><div><div><p>1000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are none, gzip, snappy, lz4, or zstd. Compression is of full batches of data, so the efficacy of batching will also impact the compression ratio (more batching means better compression).</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the value specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the connections maximum idle scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>An upper bound on the time to report success or failure after a call to send() returns. This limits the total time that a record will be delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retriable send failures. The producer may report failure to send a record earlier than this config if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch which reached an earlier delivery expiration deadline. The value of this config should be greater than or equal to the sum of request.timeout.ms and linger.ms.</p></div></div></td><td><div><div><p>120</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the delivery timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection to be less than or equal to 5, retries to be greater than 0 and acks must be 'all'. If these values are not explicitly set by the user, suitable values will be chosen. If incompatible values are set, a ConnectionException will be thrown</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 waits for up to the given delay to allow other records to be sent so that the sends can be batched together. This can be thought of as analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching: once we get batch.size worth of records for a partition it is sent immediately regardless of this setting, however if we have fewer than this many bytes accumulated for this partition we will 'linger' for the specified time waiting for more records to show up. This setting defaults to 0 (i.e. no delay). Setting linger.ms=5, for example, would have the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p>0</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the linger time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls how long KafkaProducer.send() and KafkaProducer.partitionsFor() 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.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the maximum block time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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).</p></div></div></td><td><div><div><p>5</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer acknowledge mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>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</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection 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 second succeeds, then the records in the second batch may appear first. Note additionally that produce requests will be failed before the number of retries has been exhausted if the timeout configured by delivery.timeout.ms expires first before successful acknowledgment. Users should generally prefer to leave this config unset and instead use delivery.timeout.ms to control retry behavior.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the retry backoff timeout time scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry backoff timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the request timeout time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>The configuration controls which partitioning strategy is used when sending messages without providing a key or a partition.</p></div></div></td><td><div><div><p>DEFAULT</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>EncryptionType</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Consumer Sources

- [Batch Message Listener](#batch-message-listener)

- [Message Listener](#message-listener)

### Batch Message Listener

`<kafka:batch-message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a list of messages
to the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#Record">Record</a></p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#ConsumerContext">Consumer Context</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

> [!NOTE] The **Batch Message Listener** source does not support configurable streaming strategies
> because the source takes a batch of records as an input stream. The streaming strategy
> configuration is non-repeatable-stream by default for the source.

### Message Listener

`<kafka:message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a single message to
the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

## Consumer Operations

- [Commit](#commit)

- [Consume](#consume)

- [Seek](#seek)

### Commit

`<kafka:commit>`

Commits the offsets associated to a message or batch of messages consumed in a **Message Listener**.
This is a list or a single message consumed in the **Batch Message Listener** source.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumer commit key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Commit key of the last poll. This operation is valid only when used inside a flow that uses one of the sources (<strong>Batch Message Listener</strong> or <strong>Message Listener</strong>) which inserts this value as an attribute in the Mule event.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_ACK\_MODE

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ALREADY\_COMMITTED

- KAFKA:TIMEOUT

- KAFKA:SESSION\_NOT\_FOUND

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Consume

`<kafka:consume>`

Receives messages from one or more Kafka topics. This operation works similarly to the **Message
Listener** source, so all the operations that apply to that, apply to this operation as well.

> [!NOTE] The **Consume** operation does not return the `consumerCommitKey`.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Consumption timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>IMMEDIATE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ILLEGAL\_STATE

- KAFKA:TIMEOUT

- KAFKA:SERIALIZATION\_ERROR

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Seek

`<kafka:seek>`

Sets the current offset of the consumer for the given topic and partition to the provided offset
value.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which the <strong>Seek</strong> operation is performed.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number that has its offset modified.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:INVALID\_TOPIC

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

## Producer Operations

- [Bulk Publish](#bulkPublish)

- [Publish](#publish)

### Bulk Publish

`<kafka:bulk-publish>`

Publishes a bulk of messages to the specified Kafka topic, optionally specifying the partition, key,
and message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of <a href="#KafkaMessage">Kafka Message</a></p></div></div></td><td><div><div><p>List of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:AUTHENTICATION\_ERROR

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

### Publish

`<kafka:publish>`

Publishes a message to the specified Kafka topic, optionally specifying the partition, key, and
message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) Topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p><a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

## Object Types

- [Consumer Context](#ConsumerContext)

- [CRL File](#CrlFile)

- [Custom OCSP Responder](#CustomOcspResponder)

- [Expiration Policy](#ExpirationPolicy)

- [Kafka Message](#KafkaMessage)

- [Kafka Message Attributes](#KafkaMessageAttributes)

- [Kafka Message Metadata](#KafkaMessageMetadata)

- [Kafka Record Attributes](#KafkaRecordAttributes)

- [Keystore](#KeyStore)

- [Proxy Config Params](#ProxyConfigParams)

- [Reconnect](#Reconnect)

- [Reconnect Forever](#Reconnect-Forever)

- [Reconnection](#Reconnection)

- [Record](#Record)

- [Redelivery Policy](#RedeliveryPolicy)

- [Repeatable File Store Stream](#RepeatableFileStoreStream)

- [Repeatable In Memory Stream](#RepeatableInMemoryStream)

- [Standard Revocation Check](#StandardRevocationCheck)

- [Tcp Client Socket Params](#TcpClientSocketParams)

- [TLS](#Tls)

- [Topic Partition](#TopicPartition)

- [Truststore](#TrustStore)

### Consumer Context

Type for the consumer context.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### CRL File

Specifies the location of the certification revocation list (CRL) file.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the CRL file.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Custom OCSP Responder

Configures a custom OCSP responder for certification revocation checks.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Url</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>URL of the OCSP responder.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Cert Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the signing certificate for the OCSP response. If specified, the alias must be in the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Expiration Policy

Configures an expiration policy strategy.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Idle Time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Configures the maximum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Max Idle Time</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message

Represents a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaMessageAttributes">Kafka Message Attributes</a></p></div></div></td><td><div><div><p>Attributes associated with the Kafka message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Attributes

Represents the attributes of a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Headers of the Kafka message, represented as a map in which the key is a string and the value is an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Key of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the topic where the Kafka message is sent.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to which the Kafka message belongs to.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Metadata

Metadata of the Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Record Attributes

Attributes of the Kafka record.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Creation Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of record creation.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Map of HTTP headers in the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Keys of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Leader Epoch</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Leader epoch of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Log Append Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Log append timestamp of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Keystore

Configures the keystore for the TLS protocol. The keystore you generate contains a private key and a
public certificate.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the keystore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the key to use when the keystore contains multiple private keys. By default, Mule uses the first key in the file.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the private key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the keystore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Proxy Config Params

Configures the proxy configuration parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Host</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Hostname or IP address of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Port</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Port of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect

Configures a standard reconnection strategy, which specifies how often to reconnect and how many
reconnection attempts the connector source or operation can make.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How many reconnection attempts the Mule app can make.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect Forever

Configures a forever reconnection strategy by which the connector source or operation attempts to
reconnect at a specified frequency for as long as the Mule app runs.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnection

Configures a reconnection strategy for an operation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Fails Deployment</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if, when an app is deployed, a connectivity test does not pass after exhausting the associated reconnection strategy:</p></div><div><ul><li><p><code>true</code></p><div><p>Allow the deployment to fail.</p></div></li><li><p><code>false</code></p><div><p>Ignore the results of the connectivity test.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Reconnection strategy to use.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Record

Type for records.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td><td><div><div><p>Kafka record attributes.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload for the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Redelivery Policy

Configures the redelivery policy for executing requests that generate errors. You can add a
redelivery policy to any source in a flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Redelivery Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of times that a redelivered request can be processed unsuccessfully before returning a REDELIVERY_EXHAUSTED error.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Secure Hash</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule uses a secure hash algorithm to identify a redelivered message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message Digest Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Secure hashing algorithm to use if the <strong>Use Secure Hash</strong> field is <code>true</code>. If the payload of the message is a Java object, Mule ignores this value and returns the value that the payload’s <code>hashCode()</code> returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Id Expression</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if <strong>Use Secure Hash</strong> is <code>false</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Object Store</strong></p></td><td><div><div><p>ObjectStore</p></div></div></td><td><div><div><p>Configures the object store that stores the redelivery counter for each message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable File Store Stream

Configures the repeatable file-store streaming strategy by which Mule keeps a portion of the stream
content in memory. If the stream content is larger than the configured buffer size, Mule backs up
the buffer’s content to disk and then clears the memory.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>In Memory Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory that the stream can use for data. If the amount of memory exceeds this value, Mule buffers the content to disk. To optimize performance:</p></div><div><ul><li><p>Configure a larger buffer size to avoid the number of times Mule needs to write the buffer on disk. This increases performance, but it also limits the number of concurrent requests your application can process, because it requires additional memory.</p></li><li><p>Configure a smaller buffer size to decrease memory load at the expense of response time.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>In Memory Size</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable In Memory Stream

Configures the in-memory streaming strategy by which the request fails if the data exceeds the MAX
buffer size. Always run performance tests to find the optimal buffer size for your specific use
case.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Initial Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Initial amount of memory to allocate to the data stream. If the streamed data exceeds this value, the buffer expands by <strong>Buffer Size Increment</strong>, with an upper limit of <strong>Max In Memory Size value</strong>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Size Increment</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount by which the buffer size expands if it exceeds its initial size. Setting a value of <code>0</code> or lower specifies that the buffer can’t expand.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory to use. If more than that is used then a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised. A value lower than or equal to zero means no limit.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>Initial Buffer Size</strong>, <strong>Buffer Size Increment</strong>, and <strong>Buffer Unit</strong> fields.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Standard Revocation Check

Configures standard revocation checks for TLS certificates.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Only End Entities</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Which elements to verify in the certificate chain:</p></div><div><ul><li><p><code>true</code></p><div><p>Verify only the last element in the certificate chain.</p></div></li><li><p><code>false</code></p><div><p>Verify all elements in the certificate chain.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Prefer Crls</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>How to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Check the Certification Revocation List (CRL) for certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Use the Online Certificate Status Protocol (OCSP) to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>No Fallback</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to use the secondary method to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Use the method that wasn’t specified in the <strong>Prefer Crls</strong> field (the secondary method) to check certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Do not use the secondary method to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Soft Fail</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if the revocation server can’t be reached or is busy:</p></div><div><ul><li><p><code>true</code></p><div><p>Avoid verification failure.</p></div></li><li><p><code>false</code></p><div><p>Allow the verification to fail.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Tcp Client Socket Params

Configures the TCP client socket parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Send Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer (in bytes) used when sending data, set on the socket itself.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Receive Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Buffer size.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_TIMEOUT</code> value on sockets. Indicates the amount of time (in milliseconds) that the socket waits in a blocking operation before failing. A value of 0 (the default) means waiting indefinitely.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Send Tcp No Delay</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If set, data is sent immediately rather than being collected for efficiency, prioritizing latency over network traffic reduction. Despite the socket default being false, this option defaults to true because reducing network traffic is generally not a major concern.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_LINGER</code> value in milliseconds. This determines how long the socket remains open to ensure all remaining data is transmitted correctly before closing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Keep Alive</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Enables the <code>SO_KEEPALIVE</code> behavior on open sockets. This option periodically checks idle socket connections and closes them if they become unavailable. It is used by server sockets to control whether connections are kept alive before being recycled.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How long the connector waits before timing out when establishing a connection to the remote service.</p></div></div></td><td><div><div><p><code>30000</code></p></div></div></td><td><div></div></td></tr></tbody></table>

### TLS

Configures TLS to provide secure communications for the Mule app.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Enabled Protocols</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of protocols enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Enabled Cipher Suites</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of cipher suites enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Trust Store</strong></p></td><td><div><div><p><a href="#TrustStore">Truststore</a></p></div></div></td><td><div><div><p>Configures the TLS truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Store</strong></p></td><td><div><div><p><a href="#KeyStore">Keystore</a></p></div></div></td><td><div><div><p>Configures the TLS keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Revocation Check</strong></p></td><td><div><div><ul><li><p><a href="#StandardRevocationCheck">Standard Revocation Check</a></p></li><li><p><a href="#CustomOcspResponder">Custom OCSP Responder</a></p></li><li><p><a href="#CrlFile">CRL File</a></p></li></ul></div></div></td><td><div><div><p>Configures a revocation checking mechanism.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Topic Partition

Type for topic partition.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of partitions.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

### Truststore

Configures the truststore for TLS.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the truststore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the truststore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Insecure</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule stops performing certificate validations. Setting this to <code>true</code> can make connections vulnerable to attacks.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=9a089d7f781de8b14a4b61ac2a98bc0ab4f73e6fbe19e13a1bfd908241420063 url=/mulesoft/current/en-us/kafka-connector/4.13/index.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Apache Kafka Connector 4.13

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system and achieve seamless integration between your Mule app and a Kafka cluster,
using Mule runtime engine (Mule).

For compatibility information, see the Apache Kafka Connector Release Notes.

## Before You Begin

Before creating an app, you must:

- Have access to the Apache Kafka target resource and Anypoint Platform

- Understand how to create a Mule app using Anypoint Studio

- Have access to Apache Kafka to get values for the fields that appear in Studio

## Common Use Cases for the Connector

Common use cases for Apache Kafka Connector include:

- **Log Aggregation**

  Leverage the low-latency processing from Apache Kafka to collect logs from multiple services and
  make them available in a standard format to multiple consumers. For example, you can publish a
  message to Apache Kafka and then retrieve it.

- **Analysis and Metrics**

  Optimize your advertising budget by integrating Apache Kafka and your big data analytics solution
  to analyze end user activity, such as page views, clicks, shares, and so on, to serve relevant
  ads. For example, a department store can use a website activity tracker to improve the online
  shopping experience. The gathered data is sent to multiple departments for various computations.
  Each department reviews the received information to stay informed about what the customer is
  looking for and then provides recommendations accordingly.

- **Notifications and Alerts**

  Notify customers about various financial events, such as the recent amount of a transaction or
  more complex events like future investment suggestions based on integrations with credit agencies,
  location, and so on.

- **Time-Sensitive Applications**

  Build integration applications that are time-sensitive. For example, you can build an application
  that ensures that patients in a hospital receive the care they need in a timely manner with a
  hospital server that processes emergency requests for patient admissions and orders the requests
  based on priority determined by specified criteria. In this scenario, an application processes
  Apache Kafka messages in the order that they are received, relying on the order and idempotency of
  the messages sent through the queue. For example, a newsroom can use the Apache Kafka system to
  deliver the latest news. Retrieve the latest news by building an integration application by
  reading from the end of the Apache Kafka queue first.

For examples of these use cases, refer to
[Apache Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-examples).

### Publish-to Use Cases

With Kafka Connector, applications can publish binary messages to the Kafka server. Some examples of
use cases include:

- Publishing binary data to the Kafka server and the underlying topic.

- Setting the batch size of the data to publish to Kafka when working with large volumes of data.

  - To optimize for performance, companies can batch messages to send. Kafka stores the message
    until the batch size is reached and completes the send at that time.

- Configuring the message size to send to focus on optimal performance.

  - Kafka is not intended to process and handle large messages. Messages are typically in the 1 MB
    range and users set the size to avoid performance degradation. In the case of an error, the
    message is rejected.

- Blocking further commits on a configurable level of acknowledgment for the messages published to
  the Kafka server to ensure successful data transmission.

  - Acknowledgments enable users to ensure that the message is sent prior to publishing more
    messages. This is specifically useful in time-ordered or event-ordered messages, such as logs or
    patient drug administration orders. Ensuring that messages are sent in order helps the
    downstream application process the messages in the right order.

- Configuring how data is serialized during a publish.

- Securing messages sent during Mutual TLS.

The following lists the acceptance criteria for publishing:

- Publish a message to a Kafka topic.

- Configure the batch size and size of the message.

- Obtain an acknowledgment once publishing is complete at the configured level.

- Send the message securely via Mutual TLS.

- Configure the serialization type.

### Subscribe-from Use Cases

With Kafka Connector, applications can obtain messages from Kafka for further consumption
downstream. Some examples of use cases include:

Reading from Kafka:

- Subscribing to the Kafka server and the underlying group to read and consume messages for
  downstream processing.

- Subscribing to a specific Kafka partition to process messages.

  - Users with a high availability microservice don’t want to rely on Kafka’s rebalancing in the
    event of a failure.

  - If users have a local state associated with their partition, they want to process only that
    partition.

- Configuring the offset value to a set value or to the beginning or end of the topic.

  - Users have a local store and want to use that information to start processing their records.

  - Users have time-sensitive records and want to skip to the end if the application must be
    up-to-date or skip to the beginning if it is a new application processing the records.

- Reading the offset value from an alternate storage system on restart.

  - Users have a local store with the offset information and want to read the value from their local
    storage.

- Setting the interval for which to block the receipt of messages for varying downstream processing
  intervals.

Processing the messages:

- Ensuring there is no data loss when the downstream application crashes by manually configuring
  commits to have more control.

- Storing a commit value in a local store or in the Kafka storage and blocking until the store is
  successful.

- Storing an offset asynchronously in a local store or in the Kafka storage.

- Using Kafka’s in-built capability of load-balancing with multiple applications reading from the
  same group ID.

- Configuring the number of records to process in a single call.

The following lists the acceptance criteria for subscribing:

- Read a message from Kafka from a specific partition or topic.

- Read a message from Kafka after obtaining the offset from a local store.

- Read a message from the beginning of the queue, the end of the queue, and a pre-specified offset.

- Ensure a high level of performance when there is one consumer per thread. Multiple consumers exist
  in a single group.

## Audience

- Starting user

  To create a Mule app, see [Apache Kafka Studio Configuration](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-studio).

- Power user

  Read [XML and Maven Support](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-xml-maven) and [Examples](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-examples).

## Next

After you complete the prerequisites, you are ready to create an app with
[Anypoint Studio](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-studio).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange)

- [Apache Kafka Connector](https://www.mulesoft.com/exchange/com.mulesoft.connectors/mule-kafka-connector/)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=7d2f12d8f17710ab7119e216a9bb13ff952026df070bbcf256a3a24394419f78 url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-config-topics.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Apache Kafka Connector 4.13 - Additional Configuration Information

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Set additional configuration for Anypoint Connector for Apache Kafka (Apache Kafka Connector).

## Configure a Custom Partitioner

You can configure a custom partitioner for Apache Kafka Connector in a Mule app:

1.  Use Maven to create a Java project and add the custom partitioner to it:

    ```java
    public class CustomPartitioner implements Partitioner {
    // Implementation
    }
    ```

2.  Add this dependency in the Mule app:

    ```java
    <dependencies>
     <dependency>
       <groupId>org.example</groupId>
       <artifactId>custom-partitioner</artifactId>
       <version>1.0-SNAPSHOT</version>
     </dependency>
    </dependencies>
    ```

3.  Add this dependency to `additionalPluginDependencies`:

    ```java
    <plugin>
     <groupId>org.mule.tools.maven</groupId>
     <artifactId>mule-maven-plugin</artifactId>
     <version>${mule.maven.plugin.version}</version>
     <extensions>true</extensions>
     <configuration>
      <additionalPluginDependencies>
      <plugin>
       <groupId>com.mulesoft.connectors</groupId>
       <artifactId>mule-kafka-connector</artifactId>
        <additionalDependencies>
         <dependency>
          <groupId>io.confluent</groupId>
          <artifactId>kafka-avro-serializer</artifactId>
          <version>7.6.1</version>
         </dependency>
         <dependency>
          <groupId>org.example</groupId>
          <artifactId>custom-partitioner</artifactId>
          <version>1.0-SNAPSHOT</version>
         </dependency>
        </additionalDependencies>
       </plugin>
       </additionalPluginDependencies>
       <classifier>mule-application</classifier>
     </configuration>
    </plugin>
    ```

4.  Add the custom partitioner to the producer configuration:

    ```java
    <kafka:producer-config name="Apache_Kafka_Producer_configuration"
        doc:name="Apache Kafka Producer configuration"
        doc:id="cb9de3c5-d6d2-4f9b-a255-75a9985bffb7">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="<kafka-url>" />
            </kafka:bootstrap-servers>
            <kafka:additional-properties>
                <kafka:additional-property key="key.serializer"
                    value="org.apache.kafka.common.serialization.StringSerializer" />
                <kafka:additional-property key="value.serializer"
                    value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer" />
                <kafka:additional-property key="schema.registry.url"
                    value="<schema-registry-url>" />
                <kafka:additional-property key="basic.auth.credentials.source"
                    value="USER_INFO" />
                <kafka:additional-property key="basic.auth.user.info"
                    value="user:pass" />
                <kafka:additional-property key="auto.register.schemas"
                    value="true" />
                <kafka:additional-property key="value.subject.name.strategy"
                    value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
                <kafka:additional-property key="partitioner.class"
                    value="org.example.CustomPartitioner" />
            </kafka:additional-properties>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>
    ```

## Next Step

After you complete configuring the connector, you can try the [examples](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=6960514778b4dcced7a8f5d9fb33ec0f37c898655dec0d5a87652ff876b60d1c url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-reference.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Apache Kafka Connector 4.13 Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system. It provides seamless integration between your Mule app and an Apache Kafka
cluster, using Mule runtime engine (Mule).

> [!NOTE] When a **Message Listener** or a **Batch Message Listener** uses the `MANUAL`
> acknowledgement mode, you must use a **Commit** operation at the end of the flow when the flow
> finishes successfully (either because there were no errors or because there is an **On Error
> Continue** component in the flow).

> [!NOTE] Mule server notifications are not supported because the Kafka library used in the
> connector manages network disruptions internally.

## Consumer Configuration

Configuration for consumers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#consumer-plaintext">Consumer Plaintext Connection</a></p></li><li><p><a href="#consumer-sasl-kerberos">Consumer Kerberos Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-oauth-bearer-cc-connection">Consumer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#consumer-sasl-scram">Consumer SASL/SCRAM Connection</a></p></li><li><p><a href="#consumer-sasl-plain">Consumer SASL/PLAIN Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-token-connection">Consumer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>AUTO</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait to perform a poll if data is not available in the buffer (fetched). If no value is set, the poll is returned immediately with any records that are currently available in the buffer or else returns empty if there is no data. Must not be negative.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default listener poll timeout</strong> field. This combines with <strong>Poll Timeout</strong> to define the total timeout for the polling.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait for an operation to finish. If no value is set or a negative value is set, the operation waits forever.</p></div></div></td><td><div><div><p><code>-1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default operation timeout</strong> field. This combines with <strong>Operation Timeout</strong> to define the total default timeout for the operations that use this configuration.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely. Additionally, the
connector supports only
[RFC6749 standard](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3).

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default Group ID for all the Kafka Consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p>READ_UNCOMMITTED</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether internal topics matching a subscribed pattern is excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the reconnect backoff timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. You can override this field at the source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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 parameter can be overridden at source level.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum number of records returned on a poll call to the Kafka cluster. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 session.timeout.ms, 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 rebalances.</p></div></div></td><td><div><div><p>3</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch heartbeat interval time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 group.min.session.timeout.ms and group.max.session.timeout.ms.</p></div></div></td><td><div><div><p>10</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for session timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for connections maximum idle time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>The list of subscription regular expressions to subscribe to. This topics will be automatically rebalanced between the amount of consumers of the topic.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>The list of topic-partition pairs to assign. Note that there will be no automatic rebalance of the consumers</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The minimum amount of data the server should return for a fetch request. If insufficient data is available the request waits 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 data to accumulate which can improve server throughput a bit at the cost of some additional latency. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div></div></td><td><div><div><p>BYTE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 an absolute maximum. The maximum record batch size accepted by the broker is defined via message.max.bytes (broker config) or max.message.bytes (topic config). Note that the consumer performs multiple fetches in parallel. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 message.max.bytes (broker config) or max.message.bytes (topic config). See fetch.max.bytes for limiting the consumer request size.This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch maximum wait timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>User used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

---

## Producer Configuration

Configuration for producers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#producer-plaintext">Producer Plaintext Connection</a></p></li><li><p><a href="#producer-sasl-kerberos">Producer Kerberos Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-oauth-bearer-cc-connection">Producer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#producer-sasl-scram">Producer SASL/SCRAM Connection</a></p></li><li><p><a href="#producer-sasl-plain">Producer SASL/PLAIN Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-token-connection">Producer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default topic name to use by the producer operations, overridable at the operation’s configuration level.</p></div></div></td><td><div><div><p><code>defaultTopicName</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names..</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The producer attempts 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. No attempt will be made to batch records larger than this size. Requests sent to brokers will contain multiple batches, one for each partition with data available to be sent. A small batch size will make batching less common and may reduce throughput (a batch size of zero will disable batching entirely). A very large batch size may use memory a bit more wastefully as we will always allocate a buffer of the specified batch size in anticipation of additional records.</p></div></div></td><td><div><div><p>16</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the batch size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.block.ms after which it will throw an exception. 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 used for compression (if compression is enabled) as well as for maintaining in-flight requests. The default value in the Kafka docs is of 33554432 (32MB), but this should be capped to align with expected values for mule instances in cloudhub (v0.1 core)</p></div></div></td><td><div><div><p>1000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are none, gzip, snappy, lz4, or zstd. Compression is of full batches of data, so the efficacy of batching will also impact the compression ratio (more batching means better compression).</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the value specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the connections maximum idle scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>An upper bound on the time to report success or failure after a call to send() returns. This limits the total time that a record will be delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retriable send failures. The producer may report failure to send a record earlier than this config if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch which reached an earlier delivery expiration deadline. The value of this config should be greater than or equal to the sum of request.timeout.ms and linger.ms.</p></div></div></td><td><div><div><p>120</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the delivery timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection to be less than or equal to 5, retries to be greater than 0 and acks must be 'all'. If these values are not explicitly set by the user, suitable values will be chosen. If incompatible values are set, a ConnectionException will be thrown</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 waits for up to the given delay to allow other records to be sent so that the sends can be batched together. This can be thought of as analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching: once we get batch.size worth of records for a partition it is sent immediately regardless of this setting, however if we have fewer than this many bytes accumulated for this partition we will 'linger' for the specified time waiting for more records to show up. This setting defaults to 0 (i.e. no delay). Setting linger.ms=5, for example, would have the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p>0</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the linger time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls how long KafkaProducer.send() and KafkaProducer.partitionsFor() 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.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the maximum block time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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).</p></div></div></td><td><div><div><p>5</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer acknowledge mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>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</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection 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 second succeeds, then the records in the second batch may appear first. Note additionally that produce requests will be failed before the number of retries has been exhausted if the timeout configured by delivery.timeout.ms expires first before successful acknowledgment. Users should generally prefer to leave this config unset and instead use delivery.timeout.ms to control retry behavior.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the retry backoff timeout time scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry backoff timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the request timeout time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>The configuration controls which partitioning strategy is used when sending messages without providing a key or a partition.</p></div></div></td><td><div><div><p>DEFAULT</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>EncryptionType</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Consumer Sources

- [Batch Message Listener](#batch-message-listener)

- [Message Listener](#message-listener)

### Batch Message Listener

`<kafka:batch-message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a list of messages
to the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#Record">Record</a></p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#ConsumerContext">Consumer Context</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

> [!NOTE] The **Batch Message Listener** source does not support configurable streaming strategies
> because the source takes a batch of records as an input stream. The streaming strategy
> configuration is non-repeatable-stream by default for the source.

### Message Listener

`<kafka:message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a single message to
the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

## Consumer Operations

- [Commit](#commit)

- [Consume](#consume)

- [Seek](#seek)

### Commit

`<kafka:commit>`

Commits the offsets associated to a message or batch of messages consumed in a **Message Listener**.
This is a list or a single message consumed in the **Batch Message Listener** source.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumer commit key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Commit key of the last poll. This operation is valid only when used inside a flow that uses one of the sources (<strong>Batch Message Listener</strong> or <strong>Message Listener</strong>) which inserts this value as an attribute in the Mule event.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_ACK\_MODE

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ALREADY\_COMMITTED

- KAFKA:TIMEOUT

- KAFKA:SESSION\_NOT\_FOUND

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Consume

`<kafka:consume>`

Receives messages from one or more Kafka topics. This operation works similarly to the **Message
Listener** source, so all the operations that apply to that, apply to this operation as well.

> [!NOTE] The **Consume** operation does not return the `consumerCommitKey`.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Consumption timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>IMMEDIATE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ILLEGAL\_STATE

- KAFKA:TIMEOUT

- KAFKA:SERIALIZATION\_ERROR

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Seek

`<kafka:seek>`

Sets the current offset of the consumer for the given topic and partition to the provided offset
value.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which the <strong>Seek</strong> operation is performed.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number that has its offset modified.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:INVALID\_TOPIC

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

## Producer Operations

- [Bulk Publish](#bulkPublish)

- [Publish](#publish)

### Bulk Publish

`<kafka:bulk-publish>`

Publishes a bulk of messages to the specified Kafka topic, optionally specifying the partition, key,
and message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of <a href="#KafkaMessage">Kafka Message</a></p></div></div></td><td><div><div><p>List of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:AUTHENTICATION\_ERROR

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

### Publish

`<kafka:publish>`

Publishes a message to the specified Kafka topic, optionally specifying the partition, key, and
message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) Topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p><a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

## Object Types

- [Consumer Context](#ConsumerContext)

- [CRL File](#CrlFile)

- [Custom OCSP Responder](#CustomOcspResponder)

- [Expiration Policy](#ExpirationPolicy)

- [Kafka Message](#KafkaMessage)

- [Kafka Message Attributes](#KafkaMessageAttributes)

- [Kafka Message Metadata](#KafkaMessageMetadata)

- [Kafka Record Attributes](#KafkaRecordAttributes)

- [Keystore](#KeyStore)

- [Proxy Config Params](#ProxyConfigParams)

- [Reconnect](#Reconnect)

- [Reconnect Forever](#Reconnect-Forever)

- [Reconnection](#Reconnection)

- [Record](#Record)

- [Redelivery Policy](#RedeliveryPolicy)

- [Repeatable File Store Stream](#RepeatableFileStoreStream)

- [Repeatable In Memory Stream](#RepeatableInMemoryStream)

- [Standard Revocation Check](#StandardRevocationCheck)

- [Tcp Client Socket Params](#TcpClientSocketParams)

- [TLS](#Tls)

- [Topic Partition](#TopicPartition)

- [Truststore](#TrustStore)

### Consumer Context

Type for the consumer context.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### CRL File

Specifies the location of the certification revocation list (CRL) file.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the CRL file.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Custom OCSP Responder

Configures a custom OCSP responder for certification revocation checks.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Url</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>URL of the OCSP responder.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Cert Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the signing certificate for the OCSP response. If specified, the alias must be in the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Expiration Policy

Configures an expiration policy strategy.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Idle Time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Configures the maximum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Max Idle Time</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message

Represents a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaMessageAttributes">Kafka Message Attributes</a></p></div></div></td><td><div><div><p>Attributes associated with the Kafka message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Attributes

Represents the attributes of a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Headers of the Kafka message, represented as a map in which the key is a string and the value is an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Key of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the topic where the Kafka message is sent.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to which the Kafka message belongs to.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Metadata

Metadata of the Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Record Attributes

Attributes of the Kafka record.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Creation Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of record creation.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Map of HTTP headers in the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Keys of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Leader Epoch</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Leader epoch of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Log Append Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Log append timestamp of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Keystore

Configures the keystore for the TLS protocol. The keystore you generate contains a private key and a
public certificate.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the keystore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the key to use when the keystore contains multiple private keys. By default, Mule uses the first key in the file.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the private key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the keystore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Proxy Config Params

Configures the proxy configuration parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Host</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Hostname or IP address of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Port</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Port of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect

Configures a standard reconnection strategy, which specifies how often to reconnect and how many
reconnection attempts the connector source or operation can make.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How many reconnection attempts the Mule app can make.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect Forever

Configures a forever reconnection strategy by which the connector source or operation attempts to
reconnect at a specified frequency for as long as the Mule app runs.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnection

Configures a reconnection strategy for an operation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Fails Deployment</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if, when an app is deployed, a connectivity test does not pass after exhausting the associated reconnection strategy:</p></div><div><ul><li><p><code>true</code></p><div><p>Allow the deployment to fail.</p></div></li><li><p><code>false</code></p><div><p>Ignore the results of the connectivity test.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Reconnection strategy to use.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Record

Type for records.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td><td><div><div><p>Kafka record attributes.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload for the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Redelivery Policy

Configures the redelivery policy for executing requests that generate errors. You can add a
redelivery policy to any source in a flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Redelivery Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of times that a redelivered request can be processed unsuccessfully before returning a REDELIVERY_EXHAUSTED error.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Secure Hash</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule uses a secure hash algorithm to identify a redelivered message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message Digest Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Secure hashing algorithm to use if the <strong>Use Secure Hash</strong> field is <code>true</code>. If the payload of the message is a Java object, Mule ignores this value and returns the value that the payload’s <code>hashCode()</code> returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Id Expression</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if <strong>Use Secure Hash</strong> is <code>false</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Object Store</strong></p></td><td><div><div><p>ObjectStore</p></div></div></td><td><div><div><p>Configures the object store that stores the redelivery counter for each message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable File Store Stream

Configures the repeatable file-store streaming strategy by which Mule keeps a portion of the stream
content in memory. If the stream content is larger than the configured buffer size, Mule backs up
the buffer’s content to disk and then clears the memory.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>In Memory Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory that the stream can use for data. If the amount of memory exceeds this value, Mule buffers the content to disk. To optimize performance:</p></div><div><ul><li><p>Configure a larger buffer size to avoid the number of times Mule needs to write the buffer on disk. This increases performance, but it also limits the number of concurrent requests your application can process, because it requires additional memory.</p></li><li><p>Configure a smaller buffer size to decrease memory load at the expense of response time.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>In Memory Size</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable In Memory Stream

Configures the in-memory streaming strategy by which the request fails if the data exceeds the MAX
buffer size. Always run performance tests to find the optimal buffer size for your specific use
case.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Initial Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Initial amount of memory to allocate to the data stream. If the streamed data exceeds this value, the buffer expands by <strong>Buffer Size Increment</strong>, with an upper limit of <strong>Max In Memory Size value</strong>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Size Increment</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount by which the buffer size expands if it exceeds its initial size. Setting a value of <code>0</code> or lower specifies that the buffer can’t expand.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory to use. If more than that is used then a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised. A value lower than or equal to zero means no limit.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>Initial Buffer Size</strong>, <strong>Buffer Size Increment</strong>, and <strong>Buffer Unit</strong> fields.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Standard Revocation Check

Configures standard revocation checks for TLS certificates.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Only End Entities</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Which elements to verify in the certificate chain:</p></div><div><ul><li><p><code>true</code></p><div><p>Verify only the last element in the certificate chain.</p></div></li><li><p><code>false</code></p><div><p>Verify all elements in the certificate chain.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Prefer Crls</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>How to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Check the Certification Revocation List (CRL) for certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Use the Online Certificate Status Protocol (OCSP) to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>No Fallback</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to use the secondary method to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Use the method that wasn’t specified in the <strong>Prefer Crls</strong> field (the secondary method) to check certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Do not use the secondary method to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Soft Fail</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if the revocation server can’t be reached or is busy:</p></div><div><ul><li><p><code>true</code></p><div><p>Avoid verification failure.</p></div></li><li><p><code>false</code></p><div><p>Allow the verification to fail.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Tcp Client Socket Params

Configures the TCP client socket parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Send Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer (in bytes) used when sending data, set on the socket itself.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Receive Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Buffer size.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_TIMEOUT</code> value on sockets. Indicates the amount of time (in milliseconds) that the socket waits in a blocking operation before failing. A value of 0 (the default) means waiting indefinitely.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Send Tcp No Delay</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If set, data is sent immediately rather than being collected for efficiency, prioritizing latency over network traffic reduction. Despite the socket default being false, this option defaults to true because reducing network traffic is generally not a major concern.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_LINGER</code> value in milliseconds. This determines how long the socket remains open to ensure all remaining data is transmitted correctly before closing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Keep Alive</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Enables the <code>SO_KEEPALIVE</code> behavior on open sockets. This option periodically checks idle socket connections and closes them if they become unavailable. It is used by server sockets to control whether connections are kept alive before being recycled.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How long the connector waits before timing out when establishing a connection to the remote service.</p></div></div></td><td><div><div><p><code>30000</code></p></div></div></td><td><div></div></td></tr></tbody></table>

### TLS

Configures TLS to provide secure communications for the Mule app.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Enabled Protocols</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of protocols enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Enabled Cipher Suites</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of cipher suites enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Trust Store</strong></p></td><td><div><div><p><a href="#TrustStore">Truststore</a></p></div></div></td><td><div><div><p>Configures the TLS truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Store</strong></p></td><td><div><div><p><a href="#KeyStore">Keystore</a></p></div></div></td><td><div><div><p>Configures the TLS keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Revocation Check</strong></p></td><td><div><div><ul><li><p><a href="#StandardRevocationCheck">Standard Revocation Check</a></p></li><li><p><a href="#CustomOcspResponder">Custom OCSP Responder</a></p></li><li><p><a href="#CrlFile">CRL File</a></p></li></ul></div></div></td><td><div><div><p>Configures a revocation checking mechanism.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Topic Partition

Type for topic partition.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of partitions.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

### Truststore

Configures the truststore for TLS.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the truststore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the truststore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Insecure</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule stops performing certificate validations. Setting this to <code>true</code> can make connections vulnerable to attacks.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=3413173ac5a818e73bef7c59310f6af138fe9f87256541b0a68b81d7ebb9bfde url=/mulesoft/current/en-us/kafka-connector/4.14/index.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Apache Kafka Connector 4.14

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system and achieve seamless integration between your Mule app and a Kafka cluster,
using Mule runtime engine (Mule).

For compatibility information, see the Apache Kafka Connector Release Notes.

## Before You Begin

Before creating an app, you must:

- Have access to the Apache Kafka target resource and Anypoint Platform

- Understand how to create a Mule app using Anypoint Studio

- Have access to Apache Kafka to get values for the fields that appear in Studio

## Common Use Cases for the Connector

Common use cases for Apache Kafka Connector include:

- **Log Aggregation**

  Leverage the low-latency processing from Apache Kafka to collect logs from multiple services and
  make them available in a standard format to multiple consumers. For example, you can publish a
  message to Apache Kafka and then retrieve it.

- **Analysis and Metrics**

  Optimize your advertising budget by integrating Apache Kafka and your big data analytics solution
  to analyze end user activity, such as page views, clicks, shares, and so on, to serve relevant
  ads. For example, a department store can use a website activity tracker to improve the online
  shopping experience. The gathered data is sent to multiple departments for various computations.
  Each department reviews the received information to stay informed about what the customer is
  looking for and then provides recommendations accordingly.

- **Notifications and Alerts**

  Notify customers about various financial events, such as the recent amount of a transaction or
  more complex events like future investment suggestions based on integrations with credit agencies,
  location, and so on.

- **Time-Sensitive Applications**

  Build integration applications that are time-sensitive. For example, you can build an application
  that ensures that patients in a hospital receive the care they need in a timely manner with a
  hospital server that processes emergency requests for patient admissions and orders the requests
  based on priority determined by specified criteria. In this scenario, an application processes
  Apache Kafka messages in the order that they are received, relying on the order and idempotency of
  the messages sent through the queue. For example, a newsroom can use the Apache Kafka system to
  deliver the latest news. Retrieve the latest news by building an integration application by
  reading from the end of the Apache Kafka queue first.

For examples of these use cases, refer to
[Apache Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-examples).

### Publish-to Use Cases

With Kafka Connector, applications can publish binary messages to the Kafka server. Some examples of
use cases include:

- Publishing binary data to the Kafka server and the underlying topic.

- Setting the batch size of the data to publish to Kafka when working with large volumes of data.

  - To optimize for performance, companies can batch messages to send. Kafka stores the message
    until the batch size is reached and completes the send at that time.

- Configuring the message size to send to focus on optimal performance.

  - Kafka is not intended to process and handle large messages. Messages are typically in the 1 MB
    range and users set the size to avoid performance degradation. In the case of an error, the
    message is rejected.

- Blocking further commits on a configurable level of acknowledgment for the messages published to
  the Kafka server to ensure successful data transmission.

  - Acknowledgments enable users to ensure that the message is sent prior to publishing more
    messages. This is specifically useful in time-ordered or event-ordered messages, such as logs or
    patient drug administration orders. Ensuring that messages are sent in order helps the
    downstream application process the messages in the right order.

- Configuring how data is serialized during a publish.

- Securing messages sent during Mutual TLS.

The following lists the acceptance criteria for publishing:

- Publish a message to a Kafka topic.

- Configure the batch size and size of the message.

- Obtain an acknowledgment once publishing is complete at the configured level.

- Send the message securely via Mutual TLS.

- Configure the serialization type.

### Subscribe-from Use Cases

With Kafka Connector, applications can obtain messages from Kafka for further consumption
downstream. Some examples of use cases include:

Reading from Kafka:

- Subscribing to the Kafka server and the underlying group to read and consume messages for
  downstream processing.

- Subscribing to a specific Kafka partition to process messages.

  - Users with a high availability microservice don’t want to rely on Kafka’s rebalancing in the
    event of a failure.

  - If users have a local state associated with their partition, they want to process only that
    partition.

- Configuring the offset value to a set value or to the beginning or end of the topic.

  - Users have a local store and want to use that information to start processing their records.

  - Users have time-sensitive records and want to skip to the end if the application must be
    up-to-date or skip to the beginning if it is a new application processing the records.

- Reading the offset value from an alternate storage system on restart.

  - Users have a local store with the offset information and want to read the value from their local
    storage.

- Setting the interval for which to block the receipt of messages for varying downstream processing
  intervals.

Processing the messages:

- Ensuring there is no data loss when the downstream application crashes by manually configuring
  commits to have more control.

- Storing a commit value in a local store or in the Kafka storage and blocking until the store is
  successful.

- Storing an offset asynchronously in a local store or in the Kafka storage.

- Using Kafka’s in-built capability of load-balancing with multiple applications reading from the
  same group ID.

- Configuring the number of records to process in a single call.

The following lists the acceptance criteria for subscribing:

- Read a message from Kafka from a specific partition or topic.

- Read a message from Kafka after obtaining the offset from a local store.

- Read a message from the beginning of the queue, the end of the queue, and a pre-specified offset.

- Ensure a high level of performance when there is one consumer per thread. Multiple consumers exist
  in a single group.

## Audience

- Starting user

  To create a Mule app, see [Apache Kafka Studio Configuration](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-studio).

- Power user

  Read [XML and Maven Support](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-xml-maven) and [Examples](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-examples).

## Next

After you complete the prerequisites, you are ready to create an app with
[Anypoint Studio](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-studio).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange)

- [Apache Kafka Connector](https://www.mulesoft.com/exchange/com.mulesoft.connectors/mule-kafka-connector/)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=27eea28c8360ae8002bb84c0ad5d8380d40633ce7178adbb661711269430d38e url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-config-topics.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Apache Kafka Connector 4.14 - Additional Configuration Information

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Set additional configuration for Anypoint Connector for Apache Kafka (Apache Kafka Connector).

## Configure a Custom Partitioner

You can configure a custom partitioner for Apache Kafka Connector in a Mule app:

1.  Use Maven to create a Java project and add the custom partitioner to it:

    ```java
    public class CustomPartitioner implements Partitioner {
    // Implementation
    }
    ```

2.  Add this dependency in the Mule app:

    ```java
    <dependencies>
     <dependency>
       <groupId>org.example</groupId>
       <artifactId>custom-partitioner</artifactId>
       <version>1.0-SNAPSHOT</version>
     </dependency>
    </dependencies>
    ```

3.  Add this dependency to `additionalPluginDependencies`:

    ```java
    <plugin>
     <groupId>org.mule.tools.maven</groupId>
     <artifactId>mule-maven-plugin</artifactId>
     <version>${mule.maven.plugin.version}</version>
     <extensions>true</extensions>
     <configuration>
      <additionalPluginDependencies>
      <plugin>
       <groupId>com.mulesoft.connectors</groupId>
       <artifactId>mule-kafka-connector</artifactId>
        <additionalDependencies>
         <dependency>
          <groupId>io.confluent</groupId>
          <artifactId>kafka-avro-serializer</artifactId>
          <version>7.6.1</version>
         </dependency>
         <dependency>
          <groupId>org.example</groupId>
          <artifactId>custom-partitioner</artifactId>
          <version>1.0-SNAPSHOT</version>
         </dependency>
        </additionalDependencies>
       </plugin>
       </additionalPluginDependencies>
       <classifier>mule-application</classifier>
     </configuration>
    </plugin>
    ```

4.  Add the custom partitioner to the producer configuration:

    ```java
    <kafka:producer-config name="Apache_Kafka_Producer_configuration"
        doc:name="Apache Kafka Producer configuration"
        doc:id="cb9de3c5-d6d2-4f9b-a255-75a9985bffb7">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="<kafka-url>" />
            </kafka:bootstrap-servers>
            <kafka:additional-properties>
                <kafka:additional-property key="key.serializer"
                    value="org.apache.kafka.common.serialization.StringSerializer" />
                <kafka:additional-property key="value.serializer"
                    value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer" />
                <kafka:additional-property key="schema.registry.url"
                    value="<schema-registry-url>" />
                <kafka:additional-property key="basic.auth.credentials.source"
                    value="USER_INFO" />
                <kafka:additional-property key="basic.auth.user.info"
                    value="user:pass" />
                <kafka:additional-property key="auto.register.schemas"
                    value="true" />
                <kafka:additional-property key="value.subject.name.strategy"
                    value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
                <kafka:additional-property key="partitioner.class"
                    value="org.example.CustomPartitioner" />
            </kafka:additional-properties>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>
    ```

## Next Step

After you complete configuring the connector, you can try the [examples](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=a93e9a531bb5fb8cbad1ab9b8b5e94415daf3ddb3926d34a694a7593e2b96091 url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-reference.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Apache Kafka Connector 4.14 Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system. It provides seamless integration between your Mule app and an Apache Kafka
cluster, using Mule runtime engine (Mule).

> [!NOTE] When a **Message Listener** or a **Batch Message Listener** uses the `MANUAL`
> acknowledgement mode, you must use a **Commit** operation at the end of the flow when the flow
> finishes successfully (either because there were no errors or because there is an **On Error
> Continue** component in the flow).

> [!NOTE] Mule server notifications are not supported because the Kafka library used in the
> connector manages network disruptions internally.

## Consumer Configuration

Configuration for consumers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#consumer-plaintext">Consumer Plaintext Connection</a></p></li><li><p><a href="#consumer-sasl-kerberos">Consumer Kerberos Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-oauth-bearer-cc-connection">Consumer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#consumer-sasl-scram">Consumer SASL/SCRAM Connection</a></p></li><li><p><a href="#consumer-sasl-plain">Consumer SASL/PLAIN Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-token-connection">Consumer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>AUTO</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait to perform a poll if data is not available in the buffer (fetched). If no value is set, the poll is returned immediately with any records that are currently available in the buffer or else returns empty if there is no data. Must not be negative.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default listener poll timeout</strong> field. This combines with <strong>Poll Timeout</strong> to define the total timeout for the polling.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait for an operation to finish. If no value is set or a negative value is set, the operation waits forever.</p></div></div></td><td><div><div><p><code>-1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default operation timeout</strong> field. This combines with <strong>Operation Timeout</strong> to define the total default timeout for the operations that use this configuration.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely. Additionally, the
connector supports only
[RFC6749 standard](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3).

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default Group ID for all the Kafka Consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p>READ_UNCOMMITTED</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether internal topics matching a subscribed pattern is excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the reconnect backoff timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. You can override this field at the source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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 parameter can be overridden at source level.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum number of records returned on a poll call to the Kafka cluster. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 session.timeout.ms, 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 rebalances.</p></div></div></td><td><div><div><p>3</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch heartbeat interval time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 group.min.session.timeout.ms and group.max.session.timeout.ms.</p></div></div></td><td><div><div><p>10</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for session timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for connections maximum idle time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>The list of subscription regular expressions to subscribe to. This topics will be automatically rebalanced between the amount of consumers of the topic.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>The list of topic-partition pairs to assign. Note that there will be no automatic rebalance of the consumers</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The minimum amount of data the server should return for a fetch request. If insufficient data is available the request waits 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 data to accumulate which can improve server throughput a bit at the cost of some additional latency. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div></div></td><td><div><div><p>BYTE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 an absolute maximum. The maximum record batch size accepted by the broker is defined via message.max.bytes (broker config) or max.message.bytes (topic config). Note that the consumer performs multiple fetches in parallel. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 message.max.bytes (broker config) or max.message.bytes (topic config). See fetch.max.bytes for limiting the consumer request size.This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch maximum wait timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>User used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

---

## Producer Configuration

Configuration for producers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#producer-plaintext">Producer Plaintext Connection</a></p></li><li><p><a href="#producer-sasl-kerberos">Producer Kerberos Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-oauth-bearer-cc-connection">Producer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#producer-sasl-scram">Producer SASL/SCRAM Connection</a></p></li><li><p><a href="#producer-sasl-plain">Producer SASL/PLAIN Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-token-connection">Producer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default topic name to use by the producer operations, overridable at the operation’s configuration level.</p></div></div></td><td><div><div><p><code>defaultTopicName</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names..</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The producer attempts 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. No attempt will be made to batch records larger than this size. Requests sent to brokers will contain multiple batches, one for each partition with data available to be sent. A small batch size will make batching less common and may reduce throughput (a batch size of zero will disable batching entirely). A very large batch size may use memory a bit more wastefully as we will always allocate a buffer of the specified batch size in anticipation of additional records.</p></div></div></td><td><div><div><p>16</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the batch size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.block.ms after which it will throw an exception. 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 used for compression (if compression is enabled) as well as for maintaining in-flight requests. The default value in the Kafka docs is of 33554432 (32MB), but this should be capped to align with expected values for mule instances in cloudhub (v0.1 core)</p></div></div></td><td><div><div><p>1000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are none, gzip, snappy, lz4, or zstd. Compression is of full batches of data, so the efficacy of batching will also impact the compression ratio (more batching means better compression).</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the value specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the connections maximum idle scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>An upper bound on the time to report success or failure after a call to send() returns. This limits the total time that a record will be delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retriable send failures. The producer may report failure to send a record earlier than this config if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch which reached an earlier delivery expiration deadline. The value of this config should be greater than or equal to the sum of request.timeout.ms and linger.ms.</p></div></div></td><td><div><div><p>120</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the delivery timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection to be less than or equal to 5, retries to be greater than 0 and acks must be 'all'. If these values are not explicitly set by the user, suitable values will be chosen. If incompatible values are set, a ConnectionException will be thrown</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 waits for up to the given delay to allow other records to be sent so that the sends can be batched together. This can be thought of as analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching: once we get batch.size worth of records for a partition it is sent immediately regardless of this setting, however if we have fewer than this many bytes accumulated for this partition we will 'linger' for the specified time waiting for more records to show up. This setting defaults to 0 (i.e. no delay). Setting linger.ms=5, for example, would have the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p>0</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the linger time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls how long KafkaProducer.send() and KafkaProducer.partitionsFor() 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.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the maximum block time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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).</p></div></div></td><td><div><div><p>5</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer acknowledge mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>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</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection 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 second succeeds, then the records in the second batch may appear first. Note additionally that produce requests will be failed before the number of retries has been exhausted if the timeout configured by delivery.timeout.ms expires first before successful acknowledgment. Users should generally prefer to leave this config unset and instead use delivery.timeout.ms to control retry behavior.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the retry backoff timeout time scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry backoff timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the request timeout time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>The configuration controls which partitioning strategy is used when sending messages without providing a key or a partition.</p></div></div></td><td><div><div><p>DEFAULT</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>EncryptionType</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Consumer Sources

- [Batch Message Listener](#batch-message-listener)

- [Message Listener](#message-listener)

### Batch Message Listener

`<kafka:batch-message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a list of messages
to the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#Record">Record</a></p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#ConsumerContext">Consumer Context</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

> [!NOTE] The **Batch Message Listener** source does not support configurable streaming strategies
> because the source takes a batch of records as an input stream. The streaming strategy
> configuration is non-repeatable-stream by default for the source.

### Message Listener

`<kafka:message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a single message to
the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

## Consumer Operations

- [Commit](#commit)

- [Consume](#consume)

- [Seek](#seek)

### Commit

`<kafka:commit>`

Commits the offsets associated to a message or batch of messages consumed in a **Message Listener**.
This is a list or a single message consumed in the **Batch Message Listener** source.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumer commit key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Commit key of the last poll. This operation is valid only when used inside a flow that uses one of the sources (<strong>Batch Message Listener</strong> or <strong>Message Listener</strong>) which inserts this value as an attribute in the Mule event.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_ACK\_MODE

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ALREADY\_COMMITTED

- KAFKA:TIMEOUT

- KAFKA:SESSION\_NOT\_FOUND

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Consume

`<kafka:consume>`

Receives messages from one or more Kafka topics. This operation works similarly to the **Message
Listener** source, so all the operations that apply to that, apply to this operation as well.

> [!NOTE] The **Consume** operation does not return the `consumerCommitKey`.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Consumption timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>IMMEDIATE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ILLEGAL\_STATE

- KAFKA:TIMEOUT

- KAFKA:SERIALIZATION\_ERROR

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Seek

`<kafka:seek>`

Sets the current offset of the consumer for the given topic and partition to the provided offset
value.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which the <strong>Seek</strong> operation is performed.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number that has its offset modified.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:INVALID\_TOPIC

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

## Producer Operations

- [Bulk Publish](#bulkPublish)

- [Publish](#publish)

### Bulk Publish

`<kafka:bulk-publish>`

Publishes a bulk of messages to the specified Kafka topic, optionally specifying the partition, key,
and message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of <a href="#KafkaMessage">Kafka Message</a></p></div></div></td><td><div><div><p>List of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:AUTHENTICATION\_ERROR

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

### Publish

`<kafka:publish>`

Publishes a message to the specified Kafka topic, optionally specifying the partition, key, and
message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) Topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p><a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

## Object Types

- [Consumer Context](#ConsumerContext)

- [CRL File](#CrlFile)

- [Custom OCSP Responder](#CustomOcspResponder)

- [Expiration Policy](#ExpirationPolicy)

- [Kafka Message](#KafkaMessage)

- [Kafka Message Attributes](#KafkaMessageAttributes)

- [Kafka Message Metadata](#KafkaMessageMetadata)

- [Kafka Record Attributes](#KafkaRecordAttributes)

- [Keystore](#KeyStore)

- [Proxy Config Params](#ProxyConfigParams)

- [Reconnect](#Reconnect)

- [Reconnect Forever](#Reconnect-Forever)

- [Reconnection](#Reconnection)

- [Record](#Record)

- [Ser Byte Array](#SerByteArray)

- [Redelivery Policy](#RedeliveryPolicy)

- [Repeatable File Store Stream](#RepeatableFileStoreStream)

- [Repeatable In Memory Stream](#RepeatableInMemoryStream)

- [Standard Revocation Check](#StandardRevocationCheck)

- [Tcp Client Socket Params](#TcpClientSocketParams)

- [TLS](#Tls)

- [Topic Partition](#TopicPartition)

- [Truststore](#TrustStore)

### Consumer Context

Type for the consumer context.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### CRL File

Specifies the location of the certification revocation list (CRL) file.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the CRL file.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Custom OCSP Responder

Configures a custom OCSP responder for certification revocation checks.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Url</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>URL of the OCSP responder.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Cert Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the signing certificate for the OCSP response. If specified, the alias must be in the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Expiration Policy

Configures an expiration policy strategy.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Idle Time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Configures the maximum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Max Idle Time</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message

Represents a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaMessageAttributes">Kafka Message Attributes</a></p></div></div></td><td><div><div><p>Attributes associated with the Kafka message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Attributes

Represents the attributes of a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Headers of the Kafka message, represented as a map in which the key is a string and the value is an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Key of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the topic where the Kafka message is sent.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to which the Kafka message belongs to.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Metadata

Metadata of the Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Record Attributes

Attributes of the Kafka record.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Creation Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of record creation.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Map of HTTP headers in the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Keys of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Leader Epoch</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Leader epoch of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Log Append Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Log append timestamp of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Keystore

Configures the keystore for the TLS protocol. The keystore you generate contains a private key and a
public certificate.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the keystore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the key to use when the keystore contains multiple private keys. By default, Mule uses the first key in the file.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the private key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the keystore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Proxy Config Params

Configures the proxy configuration parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Host</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Hostname or IP address of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Port</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Port of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect

Configures a standard reconnection strategy, which specifies how often to reconnect and how many
reconnection attempts the connector source or operation can make.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How many reconnection attempts the Mule app can make.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect Forever

Configures a forever reconnection strategy by which the connector source or operation attempts to
reconnect at a specified frequency for as long as the Mule app runs.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnection

Configures a reconnection strategy for an operation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Fails Deployment</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if, when an app is deployed, a connectivity test does not pass after exhausting the associated reconnection strategy:</p></div><div><ul><li><p><code>true</code></p><div><p>Allow the deployment to fail.</p></div></li><li><p><code>false</code></p><div><p>Ignore the results of the connectivity test.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Reconnection strategy to use.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Record

Type for records.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td><td><div><div><p>Kafka record attributes.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload for the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Ser Byte Array</strong></p></td><td><div><div><p><a href="#SerByteArray">Ser Byte Array</a></p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Ser Byte Array

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Input Stream</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Redelivery Policy

Configures the redelivery policy for executing requests that generate errors. You can add a
redelivery policy to any source in a flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Redelivery Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of times that a redelivered request can be processed unsuccessfully before returning a REDELIVERY_EXHAUSTED error.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Secure Hash</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule uses a secure hash algorithm to identify a redelivered message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message Digest Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Secure hashing algorithm to use if the <strong>Use Secure Hash</strong> field is <code>true</code>. If the payload of the message is a Java object, Mule ignores this value and returns the value that the payload’s <code>hashCode()</code> returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Id Expression</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if <strong>Use Secure Hash</strong> is <code>false</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Object Store</strong></p></td><td><div><div><p>ObjectStore</p></div></div></td><td><div><div><p>Configures the object store that stores the redelivery counter for each message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable File Store Stream

Configures the repeatable file-store streaming strategy by which Mule keeps a portion of the stream
content in memory. If the stream content is larger than the configured buffer size, Mule backs up
the buffer’s content to disk and then clears the memory.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>In Memory Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory that the stream can use for data. If the amount of memory exceeds this value, Mule buffers the content to disk. To optimize performance:</p></div><div><ul><li><p>Configure a larger buffer size to avoid the number of times Mule needs to write the buffer on disk. This increases performance, but it also limits the number of concurrent requests your application can process, because it requires additional memory.</p></li><li><p>Configure a smaller buffer size to decrease memory load at the expense of response time.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>In Memory Size</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable In Memory Stream

Configures the in-memory streaming strategy by which the request fails if the data exceeds the MAX
buffer size. Always run performance tests to find the optimal buffer size for your specific use
case.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Initial Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Initial amount of memory to allocate to the data stream. If the streamed data exceeds this value, the buffer expands by <strong>Buffer Size Increment</strong>, with an upper limit of <strong>Max In Memory Size value</strong>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Size Increment</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount by which the buffer size expands if it exceeds its initial size. Setting a value of <code>0</code> or lower specifies that the buffer can’t expand.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory to use. If more than that is used then a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised. A value lower than or equal to zero means no limit.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>Initial Buffer Size</strong>, <strong>Buffer Size Increment</strong>, and <strong>Buffer Unit</strong> fields.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Standard Revocation Check

Configures standard revocation checks for TLS certificates.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Only End Entities</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Which elements to verify in the certificate chain:</p></div><div><ul><li><p><code>true</code></p><div><p>Verify only the last element in the certificate chain.</p></div></li><li><p><code>false</code></p><div><p>Verify all elements in the certificate chain.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Prefer Crls</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>How to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Check the Certification Revocation List (CRL) for certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Use the Online Certificate Status Protocol (OCSP) to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>No Fallback</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to use the secondary method to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Use the method that wasn’t specified in the <strong>Prefer Crls</strong> field (the secondary method) to check certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Do not use the secondary method to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Soft Fail</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if the revocation server can’t be reached or is busy:</p></div><div><ul><li><p><code>true</code></p><div><p>Avoid verification failure.</p></div></li><li><p><code>false</code></p><div><p>Allow the verification to fail.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Tcp Client Socket Params

Configures the TCP client socket parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Send Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer (in bytes) used when sending data, set on the socket itself.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Receive Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Buffer size.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_TIMEOUT</code> value on sockets. Indicates the amount of time (in milliseconds) that the socket waits in a blocking operation before failing. A value of 0 (the default) means waiting indefinitely.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Send Tcp No Delay</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If set, data is sent immediately rather than being collected for efficiency, prioritizing latency over network traffic reduction. Despite the socket default being false, this option defaults to true because reducing network traffic is generally not a major concern.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_LINGER</code> value in milliseconds. This determines how long the socket remains open to ensure all remaining data is transmitted correctly before closing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Keep Alive</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Enables the <code>SO_KEEPALIVE</code> behavior on open sockets. This option periodically checks idle socket connections and closes them if they become unavailable. It is used by server sockets to control whether connections are kept alive before being recycled.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How long the connector waits before timing out when establishing a connection to the remote service.</p></div></div></td><td><div><div><p><code>30000</code></p></div></div></td><td><div></div></td></tr></tbody></table>

### TLS

Configures TLS to provide secure communications for the Mule app.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Enabled Protocols</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of protocols enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Enabled Cipher Suites</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of cipher suites enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Trust Store</strong></p></td><td><div><div><p><a href="#TrustStore">Truststore</a></p></div></div></td><td><div><div><p>Configures the TLS truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Store</strong></p></td><td><div><div><p><a href="#KeyStore">Keystore</a></p></div></div></td><td><div><div><p>Configures the TLS keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Revocation Check</strong></p></td><td><div><div><ul><li><p><a href="#StandardRevocationCheck">Standard Revocation Check</a></p></li><li><p><a href="#CustomOcspResponder">Custom OCSP Responder</a></p></li><li><p><a href="#CrlFile">CRL File</a></p></li></ul></div></div></td><td><div><div><p>Configures a revocation checking mechanism.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Topic Partition

Type for topic partition.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of partitions.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

### Truststore

Configures the truststore for TLS.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the truststore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the truststore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Insecure</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule stops performing certificate validations. Setting this to <code>true</code> can make connections vulnerable to attacks.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=ce53ecc4a8f2331f63d1f86807dc360b87e8073cf62c27ea62b3d4b086a2f813 url=/mulesoft/current/en-us/kafka-connector/latest/index.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Apache Kafka Connector 4.15

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system and achieve seamless integration between your Mule app and a Kafka cluster,
using Mule runtime engine (Mule).

For compatibility information, see the Apache Kafka Connector Release Notes.

## Before You Begin

Before creating an app, you must:

- Have access to the Apache Kafka target resource and Anypoint Platform

- Understand how to create a Mule app using Anypoint Studio

- Have access to Apache Kafka to get values for the fields that appear in Studio

## Common Use Cases for the Connector

Common use cases for Apache Kafka Connector include:

- **Log Aggregation**

  Leverage the low-latency processing from Apache Kafka to collect logs from multiple services and
  make them available in a standard format to multiple consumers. For example, you can publish a
  message to Apache Kafka and then retrieve it.

- **Analysis and Metrics**

  Optimize your advertising budget by integrating Apache Kafka and your big data analytics solution
  to analyze end user activity, such as page views, clicks, shares, and so on, to serve relevant
  ads. For example, a department store can use a website activity tracker to improve the online
  shopping experience. The gathered data is sent to multiple departments for various computations.
  Each department reviews the received information to stay informed about what the customer is
  looking for and then provides recommendations accordingly.

- **Notifications and Alerts**

  Notify customers about various financial events, such as the recent amount of a transaction or
  more complex events like future investment suggestions based on integrations with credit agencies,
  location, and so on.

- **Time-Sensitive Applications**

  Build integration applications that are time-sensitive. For example, you can build an application
  that ensures that patients in a hospital receive the care they need in a timely manner with a
  hospital server that processes emergency requests for patient admissions and orders the requests
  based on priority determined by specified criteria. In this scenario, an application processes
  Apache Kafka messages in the order that they are received, relying on the order and idempotency of
  the messages sent through the queue. For example, a newsroom can use the Apache Kafka system to
  deliver the latest news. Retrieve the latest news by building an integration application by
  reading from the end of the Apache Kafka queue first.

For examples of these use cases, refer to
[Apache Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-examples).

### Publish-to Use Cases

With Kafka Connector, applications can publish binary messages to the Kafka server. Some examples of
use cases include:

- Publishing binary data to the Kafka server and the underlying topic.

- Setting the batch size of the data to publish to Kafka when working with large volumes of data.

  - To optimize for performance, companies can batch messages to send. Kafka stores the message
    until the batch size is reached and completes the send at that time.

- Configuring the message size to send to focus on optimal performance.

  - Kafka is not intended to process and handle large messages. Messages are typically in the 1 MB
    range and users set the size to avoid performance degradation. In the case of an error, the
    message is rejected.

- Blocking further commits on a configurable level of acknowledgment for the messages published to
  the Kafka server to ensure successful data transmission.

  - Acknowledgments enable users to ensure that the message is sent prior to publishing more
    messages. This is specifically useful in time-ordered or event-ordered messages, such as logs or
    patient drug administration orders. Ensuring that messages are sent in order helps the
    downstream application process the messages in the right order.

- Configuring how data is serialized during a publish.

- Securing messages sent during Mutual TLS.

The following lists the acceptance criteria for publishing:

- Publish a message to a Kafka topic.

- Configure the batch size and size of the message.

- Obtain an acknowledgment once publishing is complete at the configured level.

- Send the message securely via Mutual TLS.

- Configure the serialization type.

### Subscribe-from Use Cases

With Kafka Connector, applications can obtain messages from Kafka for further consumption
downstream. Some examples of use cases include:

Reading from Kafka:

- Subscribing to the Kafka server and the underlying group to read and consume messages for
  downstream processing.

- Subscribing to a specific Kafka partition to process messages.

  - Users with a high availability microservice don’t want to rely on Kafka’s rebalancing in the
    event of a failure.

  - If users have a local state associated with their partition, they want to process only that
    partition.

- Configuring the offset value to a set value or to the beginning or end of the topic.

  - Users have a local store and want to use that information to start processing their records.

  - Users have time-sensitive records and want to skip to the end if the application must be
    up-to-date or skip to the beginning if it is a new application processing the records.

- Reading the offset value from an alternate storage system on restart.

  - Users have a local store with the offset information and want to read the value from their local
    storage.

- Setting the interval for which to block the receipt of messages for varying downstream processing
  intervals.

Processing the messages:

- Ensuring there is no data loss when the downstream application crashes by manually configuring
  commits to have more control.

- Storing a commit value in a local store or in the Kafka storage and blocking until the store is
  successful.

- Storing an offset asynchronously in a local store or in the Kafka storage.

- Using Kafka’s in-built capability of load-balancing with multiple applications reading from the
  same group ID.

- Configuring the number of records to process in a single call.

The following lists the acceptance criteria for subscribing:

- Read a message from Kafka from a specific partition or topic.

- Read a message from Kafka after obtaining the offset from a local store.

- Read a message from the beginning of the queue, the end of the queue, and a pre-specified offset.

- Ensure a high level of performance when there is one consumer per thread. Multiple consumers exist
  in a single group.

## Audience

- Starting user

  To create a Mule app, see [Apache Kafka Studio Configuration](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-studio).

- Power user

  Read [XML and Maven Support](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-xml-maven) and [Examples](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-examples).

## Next

After you complete the prerequisites, you are ready to create an app with
[Anypoint Studio](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-studio).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Use Exchange to Discover Connectors, Templates, and Examples](https://docs.mulesoft.com/connectors/introduction/intro-use-exchange)

- [Apache Kafka Connector](https://www.mulesoft.com/exchange/com.mulesoft.connectors/mule-kafka-connector/)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=d04c62aa0b80dd27f74608343c69a4219582dab91fbbd7513e587d330a6c7f95 url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-config-topics.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Apache Kafka Connector 4.15 - Additional Configuration Information

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Set additional configuration for Anypoint Connector for Apache Kafka (Apache Kafka Connector).

## Configure a Custom Partitioner

You can configure a custom partitioner for Apache Kafka Connector in a Mule app:

1.  Use Maven to create a Java project and add the custom partitioner to it:

    ```java
    public class CustomPartitioner implements Partitioner {
    // Implementation
    }
    ```

2.  Add this dependency in the Mule app:

    ```java
    <dependencies>
     <dependency>
       <groupId>org.example</groupId>
       <artifactId>custom-partitioner</artifactId>
       <version>1.0-SNAPSHOT</version>
     </dependency>
    </dependencies>
    ```

3.  Add this dependency to `additionalPluginDependencies`:

    ```java
    <plugin>
     <groupId>org.mule.tools.maven</groupId>
     <artifactId>mule-maven-plugin</artifactId>
     <version>${mule.maven.plugin.version}</version>
     <extensions>true</extensions>
     <configuration>
      <additionalPluginDependencies>
      <plugin>
       <groupId>com.mulesoft.connectors</groupId>
       <artifactId>mule-kafka-connector</artifactId>
        <additionalDependencies>
         <dependency>
          <groupId>io.confluent</groupId>
          <artifactId>kafka-avro-serializer</artifactId>
          <version>7.6.1</version>
         </dependency>
         <dependency>
          <groupId>org.example</groupId>
          <artifactId>custom-partitioner</artifactId>
          <version>1.0-SNAPSHOT</version>
         </dependency>
        </additionalDependencies>
       </plugin>
       </additionalPluginDependencies>
       <classifier>mule-application</classifier>
     </configuration>
    </plugin>
    ```

4.  Add the custom partitioner to the producer configuration:

    ```java
    <kafka:producer-config name="Apache_Kafka_Producer_configuration"
        doc:name="Apache Kafka Producer configuration"
        doc:id="cb9de3c5-d6d2-4f9b-a255-75a9985bffb7">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="<kafka-url>" />
            </kafka:bootstrap-servers>
            <kafka:additional-properties>
                <kafka:additional-property key="key.serializer"
                    value="org.apache.kafka.common.serialization.StringSerializer" />
                <kafka:additional-property key="value.serializer"
                    value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer" />
                <kafka:additional-property key="schema.registry.url"
                    value="<schema-registry-url>" />
                <kafka:additional-property key="basic.auth.credentials.source"
                    value="USER_INFO" />
                <kafka:additional-property key="basic.auth.user.info"
                    value="user:pass" />
                <kafka:additional-property key="auto.register.schemas"
                    value="true" />
                <kafka:additional-property key="value.subject.name.strategy"
                    value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
                <kafka:additional-property key="partitioner.class"
                    value="org.example.CustomPartitioner" />
            </kafka:additional-properties>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>
    ```

## Next Step

After you complete configuring the connector, you can try the [examples](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-examples).

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=64d286c66ef7aca2c9476735f7b480636be6c2d88dd7ccf2c9fc2d475c1feb71 url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-reference.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Apache Kafka Connector 4.15 Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Apache Kafka (Apache Kafka Connector) enables you to interact with the Apache
Kafka messaging system. It provides seamless integration between your Mule app and an Apache Kafka
cluster, using Mule runtime engine (Mule).

> [!NOTE] When a **Message Listener** or a **Batch Message Listener** uses the `MANUAL`
> acknowledgement mode, you must use a **Commit** operation at the end of the flow when the flow
> finishes successfully (either because there were no errors or because there is an **On Error
> Continue** component in the flow).

> [!NOTE] Mule server notifications are not supported because the Kafka library used in the
> connector manages network disruptions internally.

## Consumer Configuration

Configuration for consumers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#consumer-plaintext">Consumer Plaintext Connection</a></p></li><li><p><a href="#consumer-sasl-aws-iam">Consumer SASL/AWS IAM Connection</a></p></li><li><p><a href="#consumer-sasl-kerberos">Consumer Kerberos Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-oauth-bearer-cc-connection">Consumer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#consumer-sasl-scram">Consumer SASL/SCRAM Connection</a></p></li><li><p><a href="#consumer-sasl-plain">Consumer SASL/PLAIN Connection</a></p></li><li><p><a href="#consumer-config_consumer-sasl-token-connection">Consumer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>AUTO</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait to perform a poll if data is not available in the buffer (fetched). If no value is set, the poll is returned immediately with any records that are currently available in the buffer or else returns empty if there is no data. Must not be negative.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default listener poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default listener poll timeout</strong> field. This combines with <strong>Poll Timeout</strong> to define the total timeout for the polling.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait for an operation to finish. If no value is set or a negative value is set, the operation waits forever.</p></div></div></td><td><div><div><p><code>-1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default operation poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default operation timeout</strong> field. This combines with <strong>Operation Timeout</strong> to define the total default timeout for the operations that use this configuration.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/AWS IAM Connection Type

Use AWS Identity and Access Management (IAM) authentication to connect to an Amazon MSK cluster.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of consumers that the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum delay between invocations of <code>poll()</code> when using consumer group management. This places an upper bound on the time that a consumer can be idle before fetching more records. If <code>poll()</code> isn’t called before this timeout expires, the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> that reach this timeout, partitions aren’t immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after <code>session.timeout.ms</code> expires.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, including transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are returned in offset order. In <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns messages only up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>Messages after those belonging to ongoing transactions are withheld until the relevant transaction completes. As a result, <code>READ_COMMITTED</code> consumers can’t read to the high watermark when transactions are in flight. In <code>READ_COMMITTED</code> mode, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response isn’t received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to <code>USE_ALL_DNS_IPS</code>, when the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. This applies to both bootstrap and advertised servers. If the value is <code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code>, each entry is resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Expected time between heartbeats to the consumer coordinator when using Kafka’s group management facilities. Heartbeats ensure that the consumer’s session stays active and facilitate rebalancing when consumers join or leave the group. The value must be lower than <code>session.timeout.ms</code>, but typically should be no higher than 1/3 of that value. You can adjust it lower to control the expected time for normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate that it is active to the broker. If no heartbeats are received before the session timeout expires, the broker removes the consumer from the group and initiates a rebalance. The value must be in the allowable range configured by <code>group.min.session.timeout.ms</code> and <code>group.max.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified number of milliseconds.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration that both clients and servers can use to secure communication for the Mule app. The connector automatically sets the <code>security.protocol</code> used for communication. Valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, and <code>SASL_SSL</code>. The default is <code>PLAINTEXT</code>, or <code>SASL_PLAINTEXT</code> for SASL authentication. If the broker uses <code>SSL</code>, configure at least the keystore in the <code>tls:context</code> child element. The connector then automatically uses <code>SSL</code>, or <code>SASL_SSL</code> for SASL authentication, as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers aren’t automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this isn’t an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Access Key ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>AWS access key ID of the principal that can assume the IAM role. Leave this field empty to use the default credentials provider chain.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Secret Access Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>AWS secret access key of the principal that can assume the IAM role. Leave this field empty to use the default credentials provider chain.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Token</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>AWS session token. Specify this field only when the caller credentials are temporary, such as federated credentials, AWS SSO credentials, or credentials from a previous STS call.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Role ARN</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ARN of the IAM role to assume for MSK access through STS <code>AssumeRole</code>. This field is optional when using the default credentials provider chain without assuming a role.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Role Session Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name attached to the assumed-role session. This name appears in AWS CloudTrail audit logs.</p></div></div></td><td><div><div><p><code>mule-kafka-connector</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>AWS Region</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>AWS Region where the MSK cluster is located. This field also determines STS endpoint routing.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Try Default AWS Credentials Provider Chain</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Use the AWS default credentials provider chain instead of an explicit access key and secret access key. This works only when an AWS identity is attached to the runtime.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely. Additionally, the
connector supports only
[RFC6749 standard](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3).

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default Group ID for all the Kafka Consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p>READ_UNCOMMITTED</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether internal topics matching a subscribed pattern is excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the reconnect backoff timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. You can override this field at the source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default is used. You can override this field at the source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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 parameter can be overridden at source level.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for request timeout scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum number of records returned on a poll call to the Kafka cluster. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 session.timeout.ms, 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 rebalances.</p></div></div></td><td><div><div><p>3</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch heartbeat interval time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 group.min.session.timeout.ms and group.max.session.timeout.ms.</p></div></div></td><td><div><div><p>10</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for session timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for connections maximum idle time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>The list of subscription regular expressions to subscribe to. This topics will be automatically rebalanced between the amount of consumers of the topic.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>The list of topic-partition pairs to assign. Note that there will be no automatic rebalance of the consumers</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The minimum amount of data the server should return for a fetch request. If insufficient data is available the request waits 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 data to accumulate which can improve server throughput a bit at the cost of some additional latency. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div></div></td><td><div><div><p>BYTE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 an absolute maximum. The maximum record batch size accepted by the broker is defined via message.max.bytes (broker config) or max.message.bytes (topic config). Note that the consumer performs multiple fetches in parallel. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 message.max.bytes (broker config) or max.message.bytes (topic config). See fetch.max.bytes for limiting the consumer request size.This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the maximum partition fetch size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>500</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for fetch maximum wait timeout scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>User used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used by the client to connect to the Kafka broker.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Consumer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Group ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default group ID for all the Kafka consumers that use this configuration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Consumer Amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Determines the number of consumers the connection initially creates.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum polling interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 the expiration of this timeout, then the consumer is considered failed and the group rebalances to reassign the partitions to another member. For consumers using a non-null <code>group.instance.id</code> which reaches this timeout, partitions are not immediately reassigned. Instead, the consumer stops sending heartbeats and partitions are reassigned after the expiration of <code>session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum Polling Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum polling interval</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Isolation Level</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>READ_UNCOMMITTED</p></li><li><p>READ_COMMITTED</p></li></ul></div></div></td><td><div><div><p>Controls how to read messages that are written transactionally.</p></div><div><ul><li><p><code>READ_COMMITTED</code></p><div><p><code>consumer.poll()</code> returns only committed transactional messages are returned.</p></div></li><li><p><code>READ_UNCOMMITTED</code></p><div><p><code>consumer.poll()</code> returns all messages, even transactional messages that were aborted.</p></div></li></ul></div><div><p>Non-transactional messages are returned unconditionally in either mode. Messages are always returned in offset order. Hence, in the <code>READ_COMMITTED</code> mode, <code>consumer.poll()</code> returns only messages up to the last stable offset (LSO), which is one less than the offset of the first open transaction.</p></div><div><p>In particular, any messages appearing after messages belonging to ongoing transactions are withheld until the relevant transaction is completed. As a result, <code>READ_COMMITTED</code> consumers are not able to read up to the high watermark when there are in-flight transactions. Furthermore, when in <code>READ_COMMITTED</code>, the <code>seekToEnd</code> method returns the LSO.</p></div></div></td><td><div><div><p><code>READ_UNCOMMITTED</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Exclude internal topics</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether internal topics matching a subscribed pattern are excluded from the subscription. It is always possible to explicitly subscribe to an internal topic.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Auto offset reset</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>EARLIEST</p></li><li><p>LATEST</p></li><li><p>ERROR</p></li></ul></div></div></td><td><div><div><p>Determines what to do when there is no initial offset in Kafka or if the current offset no longer exists on the server, for example, because the data was deleted.</p></div><div><ul><li><p>EARLIEST</p><div><p>Automatically reset the offset to the earliest offset.</p></div></li><li><p>LATEST</p><div><p>Automatically reset the offset to the latest offset.</p></div></li><li><p>ERROR</p><div><p>Throw an error if no previous offset is found for the consumer’s group.</p></div></li></ul></div></div></td><td><div><div><p><code>LATEST</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Check CRC</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Automatically check the CRC32 of the records consumed. This ensures that no on-the-wire or on-disk corruption to the messages occurred. This check adds some overhead, so in situations that require extremely high performance, this can be disabled.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response of a request. If the response is not received before the timeout elapses, the client resends the request if necessary, or fails the request if the retries are exhausted. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Request Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Request Timeout</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default record limit</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of records returned on a poll call to the Kafka cluster. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat interval</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 normal rebalances.</p></div></div></td><td><div><div><p><code>3</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Heartbeat Interval Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Heartbeat interval</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout used to detect consumer failures when using Kafka’s group management facility. The consumer sends periodic heartbeats to indicate its aliveness to the broker. If no heartbeats are received by the broker before the expiration of this session timeout, then the broker removes this consumer from the group and initiates a rebalance. 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.session.timeout.ms</code>.</p></div></div></td><td><div><div><p><code>10</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Session timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Session Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the number of milliseconds specified by this configuration.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection maximum idle time time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connection maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. The default value is <code>PLAINTEXT</code> or <code>SASL_PLAINTEXT</code> for SASL authentication - kerberos/scram/plain. If the broker configures <code>SSL</code> as the protocol, then configure at least the keystore in the <code>tls:context</code> child element of the configuration and the connector automatically uses <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic Subscription Patterns</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of subscription regular expressions to which to subscribe. Topics are automatically rebalanced between the topic consumers.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Assignments</strong></p></td><td><div><div><p>Array of <a href="#TopicPartition">Topic Partition</a></p></div></div></td><td><div><div><p>List of topic-partition pairs to assign. Consumers are not automatically rebalanced.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch minimum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Minimum amount of data the server returns for a fetch request. If insufficient data is available, the request waits for the specified minimum amount of data to accumulate before answering the request. The default setting of <code>1</code> 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. If you set this to a value greater than <code>1</code>, the server waits for larger amounts of data to accumulate, which can improve server throughput slightly at the cost of some additional latency. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Minimum Size Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch minimum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>BYTE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default fetch maximum size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data the server returns for a fetch request. 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 value, the record batch is still returned to ensure that the consumer can make progress. As such, this is not an absolute maximum. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). The consumer performs multiple fetches in parallel. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum fetch size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default fetch maximum size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of data per partition that the server returns. The consumer fetches records in batches. If the first record batch in the first non-empty partition of the fetch is larger than this limit, the batch is still returned to ensure that the consumer can make progress. The maximum record batch size accepted by the broker is defined using <code>message.max.bytes</code> (broker configuration) or <code>max.message.bytes</code> (topic configuration). See <code>fetch.max.bytes</code> for limiting the consumer request size. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default maximum partition fetch unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default maximum partition fetch size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the server blocks before answering the fetch request if there isn’t sufficient data to immediately satisfy the requirement specified by <code>fetch.min.bytes</code>.</p></div></div></td><td><div><div><p><code>500</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Fetch Maximum Wait Timeout Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Fetch Maximum Wait Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

---

## Producer Configuration

Configuration for producers for Apache Kafka Connector.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name for this configuration. Connectors reference the configuration with this name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Connection</strong></p></td><td><div><div><ul><li><p><a href="#producer-plaintext">Producer Plaintext Connection</a></p></li><li><p><a href="#producer-sasl-aws-iam">Producer SASL/AWS IAM Connection</a></p></li><li><p><a href="#producer-sasl-kerberos">Producer Kerberos Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-oauth-bearer-cc-connection">Producer SASL/OAUTHBEARER - Client Credentials Connection</a></p></li><li><p><a href="#producer-sasl-scram">Producer SASL/SCRAM Connection</a></p></li><li><p><a href="#producer-sasl-plain">Producer SASL/PLAIN Connection</a></p></li><li><p><a href="#producer-config_producer-sasl-token-connection">Producer SASL/TOKEN Connection</a></p></li></ul></div></div></td><td><div><div><p>Connection types for this configuration.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Default topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Default topic name to use by the producer operations, overridable at the operation’s configuration level.</p></div></div></td><td><div><div><p><code>defaultTopicName</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Zone ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Converts the provided timestamps into <code>ZonedLocalDateTimes</code> in the results. The default value is provided by the system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Expiration Policy</strong></p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><div><div><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Plaintext Connection Type

Use an unauthenticated and non-encrypted connection type.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names..</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/AWS IAM Connection Type

Use AWS Identity and Access Management (IAM) authentication to connect to an Amazon MSK cluster.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the broker’s certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput. A batch size of <code>0</code> disables batching entirely. A very large batch size can result in more wasteful use of memory because a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but isn’t exact because not all producer memory is used for buffering. Some additional memory is used for compression, if enabled, and for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32 MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1000</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to <code>USE_ALL_DNS_IPS</code>, when the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. This applies to both bootstrap and advertised servers. If the value is <code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code>, each entry is resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed before sending, the time to await acknowledgment from the broker, and the time allowed for retrying send failures. The producer might report failure earlier than this configuration if it encounters an unrecoverable error, retries are exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. This configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of retried messages in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>, and acks to be <code>all</code>. If these values aren’t explicitly set, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer groups together records that arrive between request transmissions into a single batched request. Normally this occurs only under load when records arrive faster than they are sent. This setting adds a small artificial delay, allowing more records to be sent in the same batch. It gives the upper bound on the delay for batching. Once the specified <code>batch.size</code> worth of records is received for a partition, the batch is sent immediately. If fewer than the specified number of bytes is received, the producer waits for the specified time for more records to arrive. This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, reduces the number of requests sent but can add up to 5 ms of latency to records sent without load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> can block. These methods can be blocked because the buffer is full or metadata is unavailable. Blocking in user-supplied serializers or partitioners isn’t counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and sends fail, there is a risk of message reordering due to retries.</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends in a single request to avoid sending huge requests. It also caps the maximum record batch size. The server has its own cap on record batch size, which might be different from this value.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes the client to resend any record whose send fails with a potentially transient error. Allowing retries without setting <code>max.in.flight.requests.per.connection</code> to <code>1</code> can change the ordering of records. If two batches are sent to a single partition, the first fails and is retried but the second succeeds, the records in the second batch might appear first. Produce requests can fail before retries are exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires. It is recommended that users leave this configuration unset and use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry backoff timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response isn’t received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration that both clients and servers can use to secure communication for the Mule app. The connector automatically sets the <code>security.protocol</code> used for communication. Valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, and <code>SASL_SSL</code>. The default is <code>PLAINTEXT</code>, or <code>SASL_PLAINTEXT</code> for SASL authentication. If the broker uses <code>SSL</code>, configure at least the keystore in the <code>tls:context</code> child element. The connector then automatically uses <code>SSL</code>, or <code>SASL_SSL</code> for SASL authentication, as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Access Key ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>AWS access key ID of the principal that can assume the IAM role. Leave this field empty to use the default credentials provider chain.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Secret Access Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>AWS secret access key of the principal that can assume the IAM role. Leave this field empty to use the default credentials provider chain.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Session Token</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>AWS session token. Specify this field only when the caller credentials are temporary, such as federated credentials, AWS SSO credentials, or credentials from a previous STS call.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Role ARN</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ARN of the IAM role to assume for MSK access through STS <code>AssumeRole</code>. This field is optional when using the default credentials provider chain without assuming a role.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Role Session Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name attached to the assumed-role session. This name appears in AWS CloudTrail audit logs.</p></div></div></td><td><div><div><p><code>mule-kafka-connector</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>AWS Region</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>AWS Region where the MSK cluster is located. This field also determines STS endpoint routing.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Try Default AWS Credentials Provider Chain</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Use the AWS default credentials provider chain instead of an explicit access key and secret access key. This works only when an AWS identity is attached to the runtime.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer Kerberos Connection Type

Use Kerberos configuration files.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Entity that is authenticated by a computer system or a network. Principals can be individual people, computers, services, or computational entities such as processes and threads.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Service name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Kerberos principal name that Kafka runs as.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Kerberos configuration file (krb5.conf)</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the <code>krb5.conf</code> file, which contains Kerberos configuration information. This information includes the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm, defaults for Kerberos applications, and the mappings of hostnames to Kerberos realms.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use ticket cache</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to obtain the ticket-granting ticket (TGT) from the ticket cache. Set this option to <code>false</code> if you do not want to use the ticket cache. The connector searches for the ticket cache as follows:</p></div><div><ul><li><p>On Solaris and Linux, the connector looks in <code>/tmp/krb5cc_uid</code>, in which the <code>uid</code> is the numeric user identifier.</p></li><li><p>If the ticket cache is not available in <code>/tmp/krb5cc_uid</code> or the app is on a Windows platform, the connector looks in <code>{user.home}{file.separator}krb5cc_{user.name}</code>. You can override the ticket cache location by setting a value for the <strong>Ticket cache</strong> field.<br><br>In a Windows environment, if a ticket cannot be retrieved from the file ticket cache, Windows uses the Local Security Authority (LSA) API to get the ticket-granting ticket (TGT).</p></li></ul></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Ticket cache</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the ticket cache that contains the user’s ticket-granting ticket (TGT). If this value is set, <strong>Use ticket cache</strong> must also be set to <code>true</code>. Otherwise, a configuration error is returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use keytab</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> if you want the connector to obtain the principal’s key from the keytab. If you don’t set this value, the connector locates the keytab by using the Kerberos configuration file. If the keytab is not specified in the Kerberos configuration file, the connector looks for the <code>{user.home}{file.separator}krb5.keytab</code> file.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Keytab</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Set this option to the file name of the keytab to obtain the principal’s secret key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Store key</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Set this option to <code>true</code> to store the principal’s subject private credentials.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/OAUTHBEARER - Client Credentials Connection Type

OAuth Bearer authentication is a mechanism for authenticating requests using bearer tokens, which
are typically used to authenticate users and applications to access resources. Apache Kafka®
supports OAuth Bearer authentication for establishing connections securely.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/oauthbearer/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The endpoint identification algorithm used by clients to validate server host name. The default value is an empty string, which means it is disabled. Clients including client connections created by the broker for inter-broker communication verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The producer attempts 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. No attempt will be made to batch records larger than this size. Requests sent to brokers will contain multiple batches, one for each partition with data available to be sent. A small batch size will make batching less common and may reduce throughput (a batch size of zero will disable batching entirely). A very large batch size may use memory a bit more wastefully as we will always allocate a buffer of the specified batch size in anticipation of additional records.</p></div></div></td><td><div><div><p>16</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the batch size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.block.ms after which it will throw an exception. 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 used for compression (if compression is enabled) as well as for maintaining in-flight requests. The default value in the Kafka docs is of 33554432 (32MB), but this should be capped to align with expected values for mule instances in cloudhub (v0.1 core)</p></div></div></td><td><div><div><p>1000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to use_all_dns_ips then, when the lookup returns multiple IP addresses for a hostname, they will all be attempted to connect to before failing the connection. Applies to both bootstrap and advertised servers. If the value is resolve_canonical_bootstrap_servers_only each entry will be resolved and expanded into a list of canonical names.</p></div></div></td><td><div><div><p>USE_ALL_DNS_IPS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>The compression type for all data generated by the producer. The default is none (i.e. no compression). Valid values are none, gzip, snappy, lz4, or zstd. Compression is of full batches of data, so the efficacy of batching will also impact the compression ratio (more batching means better compression).</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the value specified by this config.</p></div></div></td><td><div><div><p>540</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the connections maximum idle scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>An upper bound on the time to report success or failure after a call to send() returns. This limits the total time that a record will be delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retriable send failures. The producer may report failure to send a record earlier than this config if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch which reached an earlier delivery expiration deadline. The value of this config should be greater than or equal to the sum of request.timeout.ms and linger.ms.</p></div></div></td><td><div><div><p>120</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the delivery timeout scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection to be less than or equal to 5, retries to be greater than 0 and acks must be 'all'. If these values are not explicitly set by the user, suitable values will be chosen. If incompatible values are set, a ConnectionException will be thrown</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 waits for up to the given delay to allow other records to be sent so that the sends can be batched together. This can be thought of as analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching: once we get batch.size worth of records for a partition it is sent immediately regardless of this setting, however if we have fewer than this many bytes accumulated for this partition we will 'linger' for the specified time waiting for more records to show up. This setting defaults to 0 (i.e. no delay). Setting linger.ms=5, for example, would have the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p>0</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the linger time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls how long KafkaProducer.send() and KafkaProducer.partitionsFor() 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.</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the maximum block time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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).</p></div></div></td><td><div><div><p>5</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the max request size scalar.</p></div></div></td><td><div><div><p>MB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer acknowledge mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>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</p></div></div></td><td><div><div><p>NONE</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>64</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the receive buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 max.in.flight.requests.per.connection 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 second succeeds, then the records in the second batch may appear first. Note additionally that produce requests will be failed before the number of retries has been exhausted if the timeout configured by delivery.timeout.ms expires first before successful acknowledgment. Users should generally prefer to leave this config unset and instead use delivery.timeout.ms to control retry behavior.</p></div></div></td><td><div><div><p>1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the retry backoff timeout time scalar.</p></div></div></td><td><div><div><p>MILLISECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry backoff timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p>100</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>128</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>The unit of measure for the send buffer size scalar. This parameter can be overridden at source level.</p></div></div></td><td><div><div><p>KB</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Determines the time unit for the request timeout time scalar.</p></div></div></td><td><div><div><p>SECONDS</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The configuration controls the maximum amount of time the client waits 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.</p></div></div></td><td><div><div><p>30</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>The configuration controls which partitioning strategy is used when sending messages without providing a key or a partition.</p></div></div></td><td><div><div><p>DEFAULT</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, which can be used from both the client and server sides to secure communication for the Mule app. The connector will automatically set the 'security.protocol' to use for communication. Valid values are PLAINTEXT / SSL / SASL_PLAINTEXT / SASL_SSL. Default value when no configuration has been provided is PLAINTEXT(or SASL_PLAINTEXT for SASL authentication - kerberos/scram/plain/token). If SSL was configured as protocol on the broker side then the user needs to configure at least the keystore in the 'tls:context' child element of this config and the connector will automatically use SSL(or SASL_SSL for SASL authentication) as 'security.protocol'.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client ID within the JAAS configuration.</p></div></div></td><td><div><div><p>clientId</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the Client ID which refers to the unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Client Secret Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth client secret within the JAAS configuration.</p></div></div></td><td><div><div><p>clientSecret</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Secret</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The value for the client secret which refers to the confidential authentication credential assigned to the OAuth client.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth token endpoint within the JAAS configuration.</p></div></div></td><td><div><div><p>sasl.oauthbearer.token.endpoint.url</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Token Endpoint</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Describes the URL where clients can request access tokens from the authentication server.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Scope Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth scope within the JAAS configuration.</p></div></div></td><td><div><div><p>scope</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Scope</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines the specific permissions and access rights granted to the client application by the authorization server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Specifies the configuration key used to define the OAuth audience within the JAAS configuration.</p></div></div></td><td><div><div><p>audience</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Audience</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma separated list of one or more target audiences for the access token.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Token Expiration Seconds</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the maximum duration, in seconds, for which an access token remains valid. This helps prevent unauthorized access by limiting the access token’s lifespan, ensuring that even if the access token is intercepted, it becomes invalid after a set period, thus enhancing security and enforcing re-authentication.</p></div><div><p>The default value is null (not set). When this field is not configured, the connector uses the actual token expiration time provided by the OAuth server in the token response (<code>expires_in</code> field). The token is valid for its full natural lifespan as determined by the authorization server. Leaving this field unset uses the OAuth server’s intended token lifespan, balances security and performance, and follows best practices.</p></div><div><p>If this value is set longer than the actual token TTL, the token expires at its natural expiration time as provided by the OAuth server, not at the configured maximum. If this value is set to the same value as the actual token TTL, the token expires at the configured time, which happens to match the server’s intended expiration time.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Principal Name</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Unique identifier associated with an authenticated user, often used for authorization decisions and resource access.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Credentials Placement</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BASIC_AUTHENTICATION_HEADER</p></li><li><p>BODY</p></li></ul></div></div></td><td><div><div><p>Defines whether to include client credentials in the basic authentication header or in the body of the authentication request.</p></div></div></td><td><div><div><p>BASIC_AUTHENTICATION_HEADER</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Module Required</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether this login module must be successfully authenticated for Kafka clients to establish a connection using OAuth 2.0 bearer tokens.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Include Accept Header</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to include 'Accept-application/json' header in the authentication request.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>OAuth Extensions</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Represents a mapping of key-value pairs containing extensions for custom broker OAuth implementations. If you specify a key for the OAuth Extensions field, ensure that the input contains only alphabetic characters and is at least one character long. If you specify a value for OAuth Extensions field, ensure the input contains only printable ASCII characters or whitespace (including space, tab, carriage return, and newline), and the value is at least one character long. You don’t need to include the <code>extension_</code> part, such as in <code>extension_logicalCluster</code> or <code>extension_identityPoolId</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Factor</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time for which the login refresh thread waits until a certain portion of the credential’s lifespan passes and attempts to refresh it. Acceptable values range from (0.5) 50% to (1.0) 100%, with a default of (0.8) 80% if unspecified.</p></div></div></td><td><div><div><p>0.8</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Window Jitter</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The maximum random jitter added to the login refresh thread’s sleep time relative to the credential’s lifespan is between (0) 0% and (0.25) 25%, with a default of (0.05) 5% if unspecified.</p></div></div></td><td><div><div><p>0.05</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Minimum Period</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The desired minimum time in seconds for the login refresh thread to wait before refreshing a credential. Legal values are between 0 and 900 (15 minutes).</p></div></div></td><td><div><div><p>60</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Login Refresh Buffer</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The amount of buffer time in seconds before credential expiration to maintain when refreshing a credential. Legal values are between 0 and 3600 (1 hour). A default value of 300 (5 minutes) is used if no value is specified.</p></div></div></td><td><div><div><p>300</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Persistent Connections</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Indicates whether to use persistent connections:</p></div><div><ul><li><p><code>true</code></p></li></ul></div><div><p>Mule uses persistent connections.</p></div><div><ul><li><p><code>false</code></p></li></ul></div><div><p>Mule closes the connection after the first request completes.</p></div></div></td><td><div><div><p>true</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Connections</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of connections to open to the backend. HTTP requests are sent in parallel over multiple connections. Setting this value too high can impact latency and consume additional resources without increasing throughput. By default, the number of connections is unlimited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Idle Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of milliseconds that a connection can remain idle before it is closed. The value of this attribute is only used when persistent connections are enabled.</p></div></div></td><td><div><div><p>30000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Stream Response</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether received responses should be streamed, meaning processing continues as soon as all headers are parsed and the body streamed as it arrives. When enabled, the response MUST be eventually read since depending on the configured buffer size it may not fit into memory and processing will stop until space is available.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer that stores the HTTP response, in bytes. By default, the space is not limited.</p></div></div></td><td><div><div><p>-1</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Socket Properties</strong></p></td><td><div><div><p><a href="#TcpClientSocketParams">Tcp Client Socket Params</a></p></div></div></td><td><div><div><p>Encapsulates the configurable properties for TCP client socket connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Proxy Config Params</strong></p></td><td><div><div><p><a href="#ProxyConfigParams">Proxy Config Params</a></p></div></div></td><td><div><div><p>Configures a proxy for outbound connections.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Follow Redirects</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Specifies whether to follow redirects or not.</p></div></div></td><td><div><div><p>false</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Response Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum time that the request element will block the execution of the flow waiting for the HTTP response.</p></div></div></td><td><div><div><p>60000</p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/SCRAM Connection Type

Use Salted Challenge Response Authentication Mechanism (SCRAM) or SASL/SCRAM, a family of SASL
mechanisms that addresses the security concerns with traditional mechanisms that perform username
and password authentication like PLAIN. Apache Kafka supports SCRAM-SHA-256 and SCRAM-SHA-512.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/scram/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of <code>0</code> disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>EncryptionType</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SHA256</p></li><li><p>SHA512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/PLAIN Connection Type

Use SASL authenticated with a username and password.

For more information, refer to the
[Confluent](https://docs.confluent.io/platform/current/security/authentication/sasl/plain/overview.html)
documentation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password with which to login.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Producer SASL/TOKEN Connection Type

Use delegation tokens to authenticate to the Kafka cluster.

> [!NOTE] Due to security reasons, a delegation token cannot be renewed if the initial
> authentication uses a delegation token. For more information, refer to
> [Delegation Token Support for Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+Delegation+token+support+for+Kafka).

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Bootstrap Server URLs</strong></p></td><td><div><div><p>Array of String</p></div></div></td><td><div><div><p>List of servers to bootstrap the connection with the Kafka cluster. This can be a partial list of the available servers. For example, <code>localhost:9071</code>.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Batch size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Producer attempts to batch records together into fewer requests whenever multiple records are sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. No attempt is made to batch records larger than this size. Requests sent to brokers contain multiple batches, one for each partition with the data that is available to send. A small batch size makes batching less common and can reduce throughput (a batch size of zero disables batching entirely). A very large batch size can result in more wasteful use of memory as a buffer of the specified batch size is always allocated in anticipation of additional records.</p></div></div></td><td><div><div><p><code>16</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The batch size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Batch size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Total bytes of memory the producer uses to buffer records waiting to send to the server. If records are sent faster than they are delivered to the server, the producer blocks for <code>max.block.ms</code>, after which it throws an exception. This setting generally corresponds to the total memory the producer uses, but is not exact because the memory used by the producer is not all used for buffering. Some additional memory is used for compression (if compression is enabled), as well as for maintaining in-flight requests. The default value in the Apache Kafka documentation is <code>33554432</code> (32MB), but this should be capped to align with expected values for Mule instances in CloudHub (v0.1 core).</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>The buffer memory size unit of measure.</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Buffer size</strong> field.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>DNS Lookups</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DEFAULT</p></li><li><p>USE_ALL_DNS_IPS</p></li><li><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></li></ul></div></div></td><td><div><div><p>Controls how the client uses DNS lookups. If set to USE_ALL_DNS_IPS then, when the lookup returns multiple IP addresses for a hostname, they attempt to connect before failing the connection. Applies to both bootstrap and advertised servers. If the value is RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY each entry is resolved and expanded into a list of canonical names.</p></div><div><ul><li><p><code>USE_ALL_DNS_IPS</code></p><div><p>When the lookup returns multiple IP addresses for a hostname, a connection is attempted to all of the IP addresses before the connection fails. Applies to both bootstrap and advertised servers.</p></div></li><li><p><code>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</code></p><div><p>Each entry is resolved and expanded into a list of canonical names.</p></div></li></ul></div></div></td><td><div><div><p><code>USE_ALL_DNS_IPS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Compression type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>GZIP</p></li><li><p>SNAPPY</p></li><li><p>LZ4</p></li><li><p>ZSTD</p></li></ul></div></div></td><td><div><div><p>Compression type for all data generated by the producer. The default is <code>NONE</code> (no compression). Compression works on full batches of data, so the efficacy of batching also impacts the compression ratio. More batching means better compression.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Close idle connections after the specified time is reached.</p></div></div></td><td><div><div><p><code>540</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connections maximum idle time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Connections maximum idle time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Upper limit on the time to report success or failure after a call to <code>send()</code> returns. This limits the total time that a record is delayed prior to sending, the time to await acknowledgment from the broker (if expected), and the time allowed for retrying send failures. The producer might report failure to send a record earlier than this configuration if either an unrecoverable error is encountered, the retries have been exhausted, or the record is added to a batch that reached an earlier delivery expiration deadline. The value of this configuration must be greater than or equal to the sum of <code>request.timeout.ms</code> and <code>linger.ms</code>.</p></div></div></td><td><div><div><p><code>120</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Delivery Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Delivery Timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Enable idempotence</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>When set to <code>true</code>, the producer ensures that exactly one copy of each message is written in the stream. If <code>false</code>, the producer retries due to broker failures and might write duplicates of the retried message in the stream. Enabling idempotence requires <code>max.in.flight.requests.per.connection</code> to be less than or equal to <code>5</code>, retries to be greater than <code>0</code>. and acks to be <code>all</code>. If these values are not explicitly set by the user, suitable values are chosen. If incompatible values are set, a <code>ConnectionException</code> is thrown.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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 are sent out. However, in some circumstances the client might want to reduce the number of requests, even under moderate load.<br><br>This setting accomplishes this by adding a small amount of artificial delay (rather than immediately sending out a record the producer waits for up to the given delay to allow other records to be sent so that the sends can be batched together). This is analogous to Nagle’s algorithm in TCP. This setting gives the upper bound on the delay for batching.<br><br>After the specified <code>batch.size</code> worth of records is received for a partition, it is sent immediately regardless of this setting, however if fewer than the specified number of bytes accumulated for this partition is received, the producer "lingers" for the specified time waiting for more records to arrive.<br><br>This setting defaults to <code>0</code> (no delay). Setting <code>linger.ms=5</code>, for example, has the effect of reducing the number of requests sent but would add up to 5ms of latency to records sent in the absence of load.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Linger time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Controls for how long <code>KafkaProducer.send()</code> and <code>KafkaProducer.partitionsFor()</code> are blocked. These methods can be blocked either because the buffer is full or the metadata <code>unavailable.Blocking</code> in the user-supplied serializers or partitioner is not counted against this timeout.</p></div></div></td><td><div><div><p><code>60</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum block time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Maximum block time</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum in flight requests</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of unacknowledged requests the client sends on a single connection before blocking. If the value is greater than <code>1</code> and there are failed sends, there is a risk of message re-ordering due to retries (if retries are enabled).</p></div></div></td><td><div><div><p><code>5</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum size of a request in bytes. This setting limits the number of record batches the producer sends 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 might be different from this.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Maximum request size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Maximum request size</strong> field.</p></div></div></td><td><div><div><p><code>MB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Producer Acknowledge Mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>LEADER_ONLY</p></li><li><p>ALL</p></li></ul></div></div></td><td><div><div><p>Number of acknowledgments the producer requires the leader to receive before considering a request complete. This controls the durability of records that are sent.</p></div></div></td><td><div><div><p><code>NONE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP receive buffer (SO_RCVBUF) to use when reading data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>64</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default receive buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default receive buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retries amount</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Setting a value greater than <code>0</code> causes 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 <code>1</code> potentially changes the ordering of records because if two batches are sent to a single partition, and the first fails and is retried but the second succeeds, then the records in the second batch might appear first. Additionally, produce requests will be failed before the number of retries has been exhausted if the timeout configured by <code>delivery.timeout.ms</code> expires before successful acknowledgment. It is recommended that users leave this configuration unset and instead use <code>delivery.timeout.ms</code> to control retry behavior.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>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.</p></div></div></td><td><div><div><p><code>100</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Retry Backoff Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Retry Backoff Timeout</strong> field.</p></div></div></td><td><div><div><p><code>MILLISECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is <code>-1</code>, the OS default is used. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>128</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default send buffer size unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit of measure for the <strong>Default send buffer size</strong> field. You can override this parameter at the source level.</p></div></div></td><td><div><div><p><code>KB</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of time the client waits for the response to a request. If the response is not received before the timeout elapses, the client resends the request if necessary or fails the request if retries are exhausted. This value must be larger than <code>replica.lag.time.max.ms</code> (a broker configuration) to reduce the possibility of message duplication due to unnecessary producer retries.</p></div></div></td><td><div><div><p><code>30</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Default request timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Default request timeout</strong> field.</p></div></div></td><td><div><div><p><code>SECONDS</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Partitioner</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NONE</p></li><li><p>DEFAULT</p></li><li><p>ROUND_ROBIN</p></li><li><p>UNIFORM_STICKY</p></li></ul></div></div></td><td><div><div><p>Controls the partitioning strategy.</p></div></div></td><td><div><div><p><code>DEFAULT</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Additional Properties</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Additional properties used to customize the Kafka connection.</p></div><div><p>For example:</p></div><div><ul><li><p>For serialization, set <strong>Key</strong> to <code>key.serializer</code> or <code>value.serializer</code> and <strong>Value</strong> to <code>com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroSerializer</code>.</p></li><li><p>For deserialization, set <strong>Key</strong> to <code>key.deserializer</code> or <code>value.deserializer</code> and <strong>Value</strong> to <code>io.confluent.kafka.serializers.KafkaAvroDeserializer</code>.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>TLS Configuration</strong></p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td><div><div><p>Defines a TLS configuration, used by both clients and server sides to secure the communication for the Mule app. The connector automatically sets the <code>security.protocol</code> to use for the communication. The valid values are <code>PLAINTEXT</code>, <code>SSL</code>, <code>SASL_PLAINTEXT</code>, or <code>SASL_SSL</code>. If the broker configures <code>SSL</code> as the protocol, configure the keystore in the <code>tls:context</code> child element of the configuration and the connector will automatically use <code>SSL</code> (or <code>SASL_SSL</code> for SASL authentication) as the <code>security.protocol</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Endpoint identification algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Endpoint identification algorithm used by clients to validate the server hostname. The default value is an empty string, which means the endpoint identification algorithm is disabled. Clients, including client connections created by the broker for inter-broker communication, verify that the broker host name matches the host name in the brokers certificate.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Token ID</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>ID of the token.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Token HMAC</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Token HMAC.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Encryption type</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>SCRAM_SHA_256</p></li><li><p>SCRAM_SHA_512</p></li></ul></div></div></td><td><div><div><p>Encryption algorithm used by SCRAM.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection</strong></p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><div><div><p>Configures a reconnection strategy to use when a connector operation fails to connect to an external server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Consumer Sources

- [Batch Message Listener](#batch-message-listener)

- [Message Listener](#message-listener)

### Batch Message Listener

`<kafka:batch-message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a list of messages
to the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#Record">Record</a></p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#ConsumerContext">Consumer Context</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

> [!NOTE] The **Batch Message Listener** source does not support configurable streaming strategies
> because the source takes a batch of records as an input stream. The streaming strategy
> configuration is non-repeatable-stream by default for the source.

### Message Listener

`<kafka:message-listener>`

This source supports the consumption of messages from a Kafka cluster, producing a single message to
the flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount of time to block. Defines the total timeout for polling.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Poll timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Amount of parallel consumers.</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of parallel consumers.</p></div></div></td><td><div><div><p><code>1</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Determines whether to execute this source on only the primary node when running Mule instances in a cluster.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

## Consumer Operations

- [Commit](#commit)

- [Consume](#consume)

- [Seek](#seek)

### Commit

`<kafka:commit>`

Commits the offsets associated to a message or batch of messages consumed in a **Message Listener**.
This is a list or a single message consumed in the **Batch Message Listener** source.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumer commit key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Commit key of the last poll. This operation is valid only when used inside a flow that uses one of the sources (<strong>Batch Message Listener</strong> or <strong>Message Listener</strong>) which inserts this value as an attribute in the Mule event.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_ACK\_MODE

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ALREADY\_COMMITTED

- KAFKA:TIMEOUT

- KAFKA:SESSION\_NOT\_FOUND

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Consume

`<kafka:consume>`

Receives messages from one or more Kafka topics. This operation works similarly to the **Message
Listener** source, so all the operations that apply to that, apply to this operation as well.

> [!NOTE] The **Consume** operation does not return the `consumerCommitKey`.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Consumption timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Acknowledgement mode</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>AUTO</p></li><li><p>MANUAL</p></li><li><p>IMMEDIATE</p></li><li><p>DUPS_OK</p></li></ul></div></div></td><td><div><div><p>Defines the way that the Kafka Broker instance is notified of the consumption of messages.</p></div><div><ul><li><p>AUTO</p><div><p>Commits messages automatically if the flow finishes successfully.</p></div></li><li><p>MANUAL</p><div><p>The user must commit messages manually upon receipt by using the <strong>Commit</strong> operation.</p></div></li><li><p>IMMEDIATE</p><div><p>Mule automatically commits the messages upon receipt before triggering the flow.</p></div></li><li><p>DUPS_OK</p><div><p>Works in the same way as MANUAL, but the commits are asynchronous, which can lead to duplicate records.</p></div></li></ul></div></div></td><td><div><div><p><code>IMMEDIATE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p><a href="#RepeatableInMemoryStream">Repeatable In Memory Stream</a></p></li><li><p><a href="#RepeatableFileStoreStream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configures how Mule processes streams. Repeatable streams are the default behavior.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:ILLEGAL\_STATE

- KAFKA:TIMEOUT

- KAFKA:SERIALIZATION\_ERROR

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

### Seek

`<kafka:seek>`

Sets the current offset of the consumer for the given topic and partition to the provided offset
value.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which the <strong>Seek</strong> operation is performed.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number that has its offset modified.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Timeout for the operation to start executing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Operation Timeout</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Associated Configurations

- [Consumer Configuration](#consumer-config)

#### Throws

- KAFKA:INVALID\_TOPIC

- KAFKA:SECURITY

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INVALID\_OFFSET

- KAFKA:INVALID\_INPUT

- KAFKA:NOT\_FOUND

- KAFKA:CONNECTIVITY

## Producer Operations

- [Bulk Publish](#bulkPublish)

- [Publish](#publish)

### Bulk Publish

`<kafka:bulk-publish>`

Publishes a bulk of messages to the specified Kafka topic, optionally specifying the partition, key,
and message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of <a href="#KafkaMessage">Kafka Message</a></p></div></div></td><td><div><div><p>List of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Array of <a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INVALID\_CONNECTION

- KAFKA:AUTHENTICATION\_ERROR

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

### Publish

`<kafka:publish>`

Publishes a message to the specified Kafka topic, optionally specifying the partition, key, and
message content for it. This operation supports transactions.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) Topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>Type of joining action that operations can take for transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Expression that evaluates the operation’s output. The outcome of the expression is stored in the <strong>Target Variable</strong> field.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p><a href="#KafkaMessageMetadata">Kafka Message Metadata</a></p></td></tr></tbody></table>

#### Associated Configurations

- [Producer Configuration](#producer-config)

#### Throws

- KAFKA:SECURITY

- KAFKA:INVALID\_TOPIC\_PARTITION

- KAFKA:RETRY\_EXHAUSTED

- KAFKA:TIMEOUT

- KAFKA:INVALID\_CONNECTION

- KAFKA:AUTHENTICATION\_ERROR

- KAFKA:INPUT\_TOO\_LARGE

- KAFKA:CONNECTIVITY

## Object Types

- [Consumer Context](#ConsumerContext)

- [CRL File](#CrlFile)

- [Custom OCSP Responder](#CustomOcspResponder)

- [Expiration Policy](#ExpirationPolicy)

- [Kafka Message](#KafkaMessage)

- [Kafka Message Attributes](#KafkaMessageAttributes)

- [Kafka Message Metadata](#KafkaMessageMetadata)

- [Kafka Record Attributes](#KafkaRecordAttributes)

- [Keystore](#KeyStore)

- [Proxy Config Params](#ProxyConfigParams)

- [Reconnect](#Reconnect)

- [Reconnect Forever](#Reconnect-Forever)

- [Reconnection](#Reconnection)

- [Record](#Record)

- [Ser Byte Array](#SerByteArray)

- [Redelivery Policy](#RedeliveryPolicy)

- [Repeatable File Store Stream](#RepeatableFileStoreStream)

- [Repeatable In Memory Stream](#RepeatableInMemoryStream)

- [Standard Revocation Check](#StandardRevocationCheck)

- [Tcp Client Socket Params](#TcpClientSocketParams)

- [TLS](#Tls)

- [Topic Partition](#TopicPartition)

- [Truststore](#TrustStore)

### Consumer Context

Type for the consumer context.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### CRL File

Specifies the location of the certification revocation list (CRL) file.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the CRL file.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Custom OCSP Responder

Configures a custom OCSP responder for certification revocation checks.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Url</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>URL of the OCSP responder.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Cert Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the signing certificate for the OCSP response. If specified, the alias must be in the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Expiration Policy

Configures an expiration policy strategy.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Idle Time</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Configures the maximum amount of time that a dynamic configuration instance can remain idle before Mule considers it eligible for expiration.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>Time unit for the <strong>Max Idle Time</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message

Represents a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaMessageAttributes">Kafka Message Attributes</a></p></div></div></td><td><div><div><p>Attributes associated with the Kafka message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Attributes

Represents the attributes of a Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Headers of the Kafka message, represented as a map in which the key is a string and the value is an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Key of the Kafka message, represented as an InputStream.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the topic where the Kafka message is sent.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic to which the Kafka message belongs to.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Message Metadata

Metadata of the Kafka message.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Kafka Record Attributes

Attributes of the Kafka record.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Consumer Commit Key</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Consumer commit key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Creation Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Timestamp of record creation.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>Map of HTTP headers in the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Keys of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Leader Epoch</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Leader epoch of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Log Append Timestamp</strong></p></td><td><div><div><p>DateTime</p></div></div></td><td><div><div><p>Log append timestamp of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Key Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized key size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Serialized Value Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Serialized value size of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic of the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Keystore

Configures the keystore for the TLS protocol. The keystore you generate contains a private key and a
public certificate.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the keystore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Alias</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Alias of the key to use when the keystore contains multiple private keys. By default, Mule uses the first key in the file.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the private key.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the keystore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Proxy Config Params

Configures the proxy configuration parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Host</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Hostname or IP address of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Port</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Port of the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Username</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Username to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password to authenticate against the proxy server.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect

Configures a standard reconnection strategy, which specifies how often to reconnect and how many
reconnection attempts the connector source or operation can make.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How many reconnection attempts the Mule app can make.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnect Forever

Configures a forever reconnection strategy by which the connector source or operation attempts to
reconnect at a specified frequency for as long as the Mule app runs.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Frequency</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How often to attempt to reconnect, in milliseconds.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Blocking</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>false</code>, the reconnection strategy runs in a separate, non-blocking thread.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Reconnection

Configures a reconnection strategy for an operation.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Fails Deployment</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if, when an app is deployed, a connectivity test does not pass after exhausting the associated reconnection strategy:</p></div><div><ul><li><p><code>true</code></p><div><p>Allow the deployment to fail.</p></div></li><li><p><code>false</code></p><div><p>Ignore the results of the connectivity test.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p><a href="#Reconnect">Reconnect</a></p></li><li><p><a href="#Reconnect-Forever">Reconnect Forever</a></p></li></ul></div></div></td><td><div><div><p>Reconnection strategy to use.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Record

Type for records.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Attributes</strong></p></td><td><div><div><p><a href="#KafkaRecordAttributes">Kafka Record Attributes</a></p></div></div></td><td><div><div><p>Kafka record attributes.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Payload</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>Payload for the record.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Ser Byte Array</strong></p></td><td><div><div><p><a href="#SerByteArray">Ser Byte Array</a></p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Ser Byte Array

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Input Stream</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Redelivery Policy

Configures the redelivery policy for executing requests that generate errors. You can add a
redelivery policy to any source in a flow.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Max Redelivery Count</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum number of times that a redelivered request can be processed unsuccessfully before returning a REDELIVERY_EXHAUSTED error.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Use Secure Hash</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule uses a secure hash algorithm to identify a redelivered message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message Digest Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Secure hashing algorithm to use if the <strong>Use Secure Hash</strong> field is <code>true</code>. If the payload of the message is a Java object, Mule ignores this value and returns the value that the payload’s <code>hashCode()</code> returned.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Id Expression</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if <strong>Use Secure Hash</strong> is <code>false</code>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Object Store</strong></p></td><td><div><div><p>ObjectStore</p></div></div></td><td><div><div><p>Configures the object store that stores the redelivery counter for each message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable File Store Stream

Configures the repeatable file-store streaming strategy by which Mule keeps a portion of the stream
content in memory. If the stream content is larger than the configured buffer size, Mule backs up
the buffer’s content to disk and then clears the memory.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>In Memory Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory that the stream can use for data. If the amount of memory exceeds this value, Mule buffers the content to disk. To optimize performance:</p></div><div><ul><li><p>Configure a larger buffer size to avoid the number of times Mule needs to write the buffer on disk. This increases performance, but it also limits the number of concurrent requests your application can process, because it requires additional memory.</p></li><li><p>Configure a smaller buffer size to decrease memory load at the expense of response time.</p></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>In Memory Size</strong> field.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Repeatable In Memory Stream

Configures the in-memory streaming strategy by which the request fails if the data exceeds the MAX
buffer size. Always run performance tests to find the optimal buffer size for your specific use
case.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Initial Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Initial amount of memory to allocate to the data stream. If the streamed data exceeds this value, the buffer expands by <strong>Buffer Size Increment</strong>, with an upper limit of <strong>Max In Memory Size value</strong>.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Size Increment</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Amount by which the buffer size expands if it exceeds its initial size. Setting a value of <code>0</code> or lower specifies that the buffer can’t expand.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Max Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Maximum amount of memory to use. If more than that is used then a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised. A value lower than or equal to zero means no limit.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Buffer Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><div><div><p>Unit for the <strong>Initial Buffer Size</strong>, <strong>Buffer Size Increment</strong>, and <strong>Buffer Unit</strong> fields.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Standard Revocation Check

Configures standard revocation checks for TLS certificates.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Only End Entities</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Which elements to verify in the certificate chain:</p></div><div><ul><li><p><code>true</code></p><div><p>Verify only the last element in the certificate chain.</p></div></li><li><p><code>false</code></p><div><p>Verify all elements in the certificate chain.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Prefer Crls</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>How to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Check the Certification Revocation List (CRL) for certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Use the Online Certificate Status Protocol (OCSP) to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>No Fallback</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Whether to use the secondary method to check certificate validity:</p></div><div><ul><li><p><code>true</code></p><div><p>Use the method that wasn’t specified in the <strong>Prefer Crls</strong> field (the secondary method) to check certificate validity.</p></div></li><li><p><code>false</code></p><div><p>Do not use the secondary method to check certificate validity.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Soft Fail</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>What to do if the revocation server can’t be reached or is busy:</p></div><div><ul><li><p><code>true</code></p><div><p>Avoid verification failure.</p></div></li><li><p><code>false</code></p><div><p>Allow the verification to fail.</p></div></li></ul></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Tcp Client Socket Params

Configures the TCP client socket parameters.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Send Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Size of the buffer (in bytes) used when sending data, set on the socket itself.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Receive Buffer Size</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Buffer size.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Client Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_TIMEOUT</code> value on sockets. Indicates the amount of time (in milliseconds) that the socket waits in a blocking operation before failing. A value of 0 (the default) means waiting indefinitely.</p></div></div></td><td><div><div><p><code>0</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Send Tcp No Delay</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If set, data is sent immediately rather than being collected for efficiency, prioritizing latency over network traffic reduction. Despite the socket default being false, this option defaults to true because reducing network traffic is generally not a major concern.</p></div></div></td><td><div><div><p><code>true</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Linger</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Sets the <code>SO_LINGER</code> value in milliseconds. This determines how long the socket remains open to ensure all remaining data is transmitted correctly before closing.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Keep Alive</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>Enables the <code>SO_KEEPALIVE</code> behavior on open sockets. This option periodically checks idle socket connections and closes them if they become unavailable. It is used by server sockets to control whether connections are kept alive before being recycled.</p></div></div></td><td><div><div><p><code>false</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Connection Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>How long the connector waits before timing out when establishing a connection to the remote service.</p></div></div></td><td><div><div><p><code>30000</code></p></div></div></td><td><div></div></td></tr></tbody></table>

### TLS

Configures TLS to provide secure communications for the Mule app.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Enabled Protocols</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of protocols enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Enabled Cipher Suites</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Comma-separated list of cipher suites enabled for this context.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Trust Store</strong></p></td><td><div><div><p><a href="#TrustStore">Truststore</a></p></div></div></td><td><div><div><p>Configures the TLS truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key Store</strong></p></td><td><div><div><p><a href="#KeyStore">Keystore</a></p></div></div></td><td><div><div><p>Configures the TLS keystore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Revocation Check</strong></p></td><td><div><div><ul><li><p><a href="#StandardRevocationCheck">Standard Revocation Check</a></p></li><li><p><a href="#CustomOcspResponder">Custom OCSP Responder</a></p></li><li><p><a href="#CrlFile">CRL File</a></p></li></ul></div></div></td><td><div><div><p>Configures a revocation checking mechanism.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

### Topic Partition

Type for topic partition.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Topic name.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Number of partitions.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

### Truststore

Configures the truststore for TLS.

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Path</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Path to the truststore. Mule resolves the path relative to the current classpath and file system.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Password</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Password used to protect the truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Type</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Type of truststore.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Algorithm</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Encryption algorithm that the truststore uses.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Insecure</strong></p></td><td><div><div><p>Boolean</p></div></div></td><td><div><div><p>If <code>true</code>, Mule stops performing certificate validations. Setting this to <code>true</code> can make connections vulnerable to attacks.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=e677059f8e931a087706f264c97ba488e42684813949d81537e6046995d5754c url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-configure-aws-iam-example.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Configure AWS IAM Authentication for Apache Kafka Connector

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Use AWS Identity and Access Management (IAM) authentication to connect Apache Kafka Connector to an
Amazon MSK cluster.

## Configure the AWS IAM Driver in the POM File

In the Mule app `pom.xml` file, configure the `aws-msk-iam-auth` dependency required for SASL/AWS
IAM authentication. Add the dependency to the `additionalPluginDependencies` section for
`mule-kafka-connector`.

```xml
<plugin>
  <groupId>org.mule.tools.maven</groupId>
  <artifactId>mule-maven-plugin</artifactId>
  <version>${mule.maven.plugin.version}</version>
  <extensions>true</extensions>
  <configuration>
    <additionalPluginDependencies>
      <plugin>
        <groupId>com.mulesoft.connectors</groupId>
        <artifactId>mule-kafka-connector</artifactId>
        <additionalDependencies>
          <dependency>
            <groupId>software.amazon.msk</groupId>
            <artifactId>aws-msk-iam-auth</artifactId>
            <version>2.3.4</version>
          </dependency>
        </additionalDependencies>
      </plugin>
    </additionalPluginDependencies>
  </configuration>
</plugin>
```

Use version `2.3.4` or later.

> [!IMPORTANT] Don’t add `aws-msk-iam-auth` as a `<dependency>` or `<sharedLibrary>`. The driver
> must resolve only through the connector’s `additionalPluginDependencies`. Adding it as a shared
> library causes a `NoClassDefFoundError` for
> `org.apache.kafka.common.security.auth.AuthenticateCallbackHandler` during deployment. If Anypoint
> Studio rewrites this block into `<sharedLibraries>`, change it back to
> `additionalPluginDependencies`.

## Configure AWS IAM Authentication

The SASL/AWS IAM connection supports two authentication modes, controlled by the **Try Default AWS
Credentials Provider Chain** field.

### Configure Static Credentials with AssumeRole

**Try Default AWS Credentials Provider Chain** is `false` by default. Provide **Access Key ID**,
**Secret Access Key**, and **Role ARN**:

```xml
<kafka:producer-config name="producer-aws-iam-config">
  <kafka:producer-sasl-aws-iam-connection
      accessKeyId="${aws.accessKeyId}"
      secretAccessKey="${aws.secretAccessKey}"
      roleArn="arn:aws:iam::123456789012:role/my-msk-client-role"
      roleSessionName="mule-producer-prod"
      region="us-east-1">
    <kafka:bootstrap-servers>
      <kafka:bootstrap-server value="b-1.my-cluster.abcde.c2.kafka.us-east-1.amazonaws.com:9098" />
    </kafka:bootstrap-servers>
  </kafka:producer-sasl-aws-iam-connection>
</kafka:producer-config>
```

If the caller credentials are temporary, such as federated credentials, AWS SSO credentials, or
credentials from a prior STS call, add **Session Token**.

```xml
<kafka:consumer-config name="consumer-aws-iam-config">
  <kafka:consumer-sasl-aws-iam-connection
      accessKeyId="${aws.accessKeyId}"
      secretAccessKey="${aws.secretAccessKey}"
      sessionToken="${aws.sessionToken}"
      roleArn="arn:aws:iam::123456789012:role/my-msk-client-role"
      roleSessionName="mule-consumer-prod"
      region="us-east-1"
      groupId="my-consumer-group"
      autoOffsetReset="EARLIEST">
    <kafka:bootstrap-servers>
      <kafka:bootstrap-server value="b-1.my-cluster.abcde.c2.kafka.us-east-1.amazonaws.com:9098" />
    </kafka:bootstrap-servers>
    <kafka:topic-patterns>
      <kafka:topic-pattern value="my-topic" />
    </kafka:topic-patterns>
  </kafka:consumer-sasl-aws-iam-connection>
</kafka:consumer-config>
```

### Configure the Default Credentials Provider Chain

Set **Try Default AWS Credentials Provider Chain** to `true` and leave **Access Key ID** and
**Secret Access Key** empty. The identity is resolved from the runtime environment, such as system
properties, environment variables, EKS IRSA, an ECS task role, an EC2 instance profile, or an
`~/.aws` profile.

For a roleless configuration, the resolved identity accesses the cluster directly:

```xml
<kafka:producer-config name="producer-aws-iam-default-chain">
  <kafka:producer-sasl-aws-iam-connection
      region="us-east-1"
      tryDefaultAwsCredentialsProviderChain="true">
    <kafka:bootstrap-servers>
      <kafka:bootstrap-server value="b-1.my-cluster.abcde.c2.kafka.us-east-1.amazonaws.com:9098" />
    </kafka:bootstrap-servers>
  </kafka:producer-sasl-aws-iam-connection>
</kafka:producer-config>
```

To use AssumeRole, specify **Role ARN** for the resolved identity. This is common for CloudHub 2.0
private spaces and Runtime Fabric on EKS:

```xml
<kafka:producer-config name="producer-aws-iam-assume-role">
  <kafka:producer-sasl-aws-iam-connection
      roleArn="arn:aws:iam::123456789012:role/my-msk-client-role"
      region="us-east-1"
      tryDefaultAwsCredentialsProviderChain="true">
    <kafka:bootstrap-servers>
      <kafka:bootstrap-server value="b-1.my-cluster.abcde.c2.kafka.us-east-1.amazonaws.com:9098" />
    </kafka:bootstrap-servers>
  </kafka:producer-sasl-aws-iam-connection>
</kafka:producer-config>
```

> [!NOTE] The default credentials provider chain works only on self-managed runtimes with an AWS
> identity attached to the environment, such as Runtime Fabric on EKS, standalone Mule on EC2, or
> CloudHub 2.0 private spaces. It doesn’t apply to CloudHub 1.0. Use static credentials with
> AssumeRole instead.

## See Also

- [Consumer SASL/AWS IAM Connection](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-reference#consumer-sasl-aws-iam)

- [Producer SASL/AWS IAM Connection](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-reference#producer-sasl-aws-iam)

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-examples)

<!-- document id=897d263abee6db4399dc74a67f1911af8d443adb61e0fd2b266d93ddbcc5ee57 url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-configure-confluent-example.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Integrate Confluent Schema Registry with Kafka Connector - Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to configure the Confluent Schema Registry using Kafka Connector.

Imagine you are developing a Mule 4 app that processes streaming data from various sources. To
ensure the data conforms to defined schemas and to manage schema evolution effectively, you
integrate Confluent Schema Registry with your Kafka Connector. This setup is crucial for developers
who need to enforce data integrity and compatibility across different versions of data producers and
consumers.

The configuration consists of two parts:

- Configuring the Confluent Schema Registry in the Kafka Connector connection using the **Additional
  Properties** field for the **Consumer** operation.

- Configuring the Kafka Avro dependency in the POM file of the Mule app

## Configure the Confluent Schema Registry in the Kafka Connector Connection

Use the **Additional Properties** field to configure the Confluent Schema Registry.

### Configure the Consumer Operation

To configure the **Consumer** operation in Anypoint Studio:

1.  Open your Mule project in Anypoint Studio and navigate to the **Global Elements** tab.

2.  Click **Create**.

3.  In the search box, type `kafka`.

4.  Select **Apache Kafka Consumer configuration**.

5.  Click **OK**.

6.  In the configuration screen under connection, select **Advanced**.

7.  Fill in all the required connection parameters.

8.  For **Additional properties**, select **Edit inline**.

9.  Click the plus sign to add a new additional property.

10. Set **Key** to `key.deserializer` and **Value** to
    `io.confluent.kafka.serializers.KafkaAvroDeserializer`.

11. Repeat step 9 to add all the required Confluent Schema Registry properties.

In the **Configuration XML** window, check the complete confluent schema registry configuration
under the `<kafka:additional-property>` tags:

```xml
<kafka:consumer-config name="Apache_Kafka_Consumer_configuration” >
<kafka:consumer-plaintext-connection groupId="JenkinsTest">
<kafka:bootstrap-servers >
	<kafka:bootstrap-server value="localhost:9092" />
	</kafka:bootstrap-servers>
<kafka:additional-properties >
  <kafka:additional-property key="key.deserializer" value="’io.confluent.kafka.serializers.KafkaAvroDeserializer” />
    <kafka:additional-property key="value.deserializer value="io.confluent.kafka.serializers.KafkaAvroDeserializer" />
       <kafka:additional-property key="schema.registry.url" value="https://example.us-east-2.aws.confluent.cloud" />
      <kafka:additional-property key="basic.auth.credentials.source" value="USER_INFO" />
      <kafka:additional-property key="basic.auth.user.info" value="<put your credentials here>" />
       <kafka:additional-property key="auto.register.schemas" value="false" />
     <kafka:additional-property key="value.subject.name.strategy" value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
        </kafka:additional-properties>
        <kafka:topic-patterns >
		<kafka:topic-pattern value="InfraTopic" />
	    </kafka:topic-patterns>
        </kafka:consumer-plaintext-connection>
	    </kafka:consumer-config>
```

## Configure the Kafka Avro dependency in the POM File

In the POM file of the Mule app, configure the Kafka Avro dependency that contains the class to use
to serialize and deserialize. You must update the `<dependencies>`, `<plugin>`, and `<repository>`
sections of the POM file.

### Configure the <dependencies> Section

In the `<dependencies>` section, set `kafka-avro-serializer`:

```xml
<dependencies>
        <dependency>
            <groupId>io.confluent</groupId>
            <artifactId>kafka-avro-serializer</artifactId>
            <version>7.4.0</version>
        </dependency>
</dependencies>
```

### Configure the <plugin> Section

In the `<plugin>` section, set `kafka-avro-serializer` as a `<sharedLibrary>`:

```xml
<plugin>
	<groupId>org.mule.tools.maven</groupId>
	<artifactId>mule-maven-plugin</artifactId>
	<version>${mule.maven.plugin.version}</version>
		<extensions>true</extensions>
				<configuration>
					<additionalPluginDependencies>
						<plugin>
							<groupId>com.mulesoft.connectors</groupId>
							<artifactId>mule-kafka-connector</artifactId>
							<additionalDependencies>
								<dependency>
									<groupId>io.confluent</groupId>
									<artifactId>kafka-avro-serializer</artifactId>
									<version>7.6.1</version>
								</dependency>
							</additionalDependencies>
						</plugin>
					</additionalPluginDependencies>
					<sharedLibraries>
						<sharedLibrary>
							<groupId>io.confluent</groupId>
							<artifactId>kafka-avro-serializer</artifactId>
						</sharedLibrary>
					</sharedLibraries>
					<classifier>mule-application</classifier>
   </configuration>
</plugin>
```

Then, set the `avro-maven-plugin` plugin. This dependency from the `org.apache.avro` group is a
plugin for Apache Maven that facilitates handling Avro schema files in Java projects. The plugin
automatically generates Java classes from Avro schemas (.avsc), protocols (.avpr), and IDL files
(.avdl). This process simplifies development by eliminating the need to manually write Java classes
that represent Avro schemas, ensuring that the Java code is always synchronized with the Avro
schemas.

The `<sourceDirectory>` specifices the folder where the Avro schemas live, for example
`<sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>`.

```xml
<plugin>
<groupId>org.apache.avro</groupId>
	<artifactId>avro-maven-plugin</artifactId>
	<version>1.10.2</version>
	<executions>
		<execution>
			<phase>generate-sources</phase>
			<goals>
				<goal>schema</goal>
			</goals>
			<configuration>
            <sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>
			</configuration>
		</execution>
	</executions>
</plugin>
```

### Configure the <repository> Section

In the `<repository>` section, configure the repository of the dependency:

```xml
<repository>
            <id>confluent</id>
            <url>https://packages.confluent.io/maven/</url>
 </repository>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-examples)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=fcbc6a1c8eae16339638465138f20ea778a14533ec96bb98c647905e75cd9599 url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-configure-confluent-example.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Integrate Confluent Schema Registry with Kafka Connector - Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to configure the Confluent Schema Registry using Kafka Connector.

Imagine you are developing a Mule 4 app that processes streaming data from various sources. To
ensure the data conforms to defined schemas and to manage schema evolution effectively, you
integrate Confluent Schema Registry with your Kafka Connector. This setup is crucial for developers
who need to enforce data integrity and compatibility across different versions of data producers and
consumers.

The configuration consists of two parts:

- Configuring the Confluent Schema Registry in the Kafka Connector connection using the **Additional
  Properties** field for the **Consumer** operation.

- Configuring the Kafka Avro dependency in the POM file of the Mule app

## Configure the Confluent Schema Registry in the Kafka Connector Connection

Use the **Additional Properties** field to configure the Confluent Schema Registry.

### Configure the Consumer Operation

To configure the **Consumer** operation in Anypoint Studio:

1.  Open your Mule project in Anypoint Studio and navigate to the **Global Elements** tab.

2.  Click **Create**.

3.  In the search box, type `kafka`.

4.  Select **Apache Kafka Consumer configuration**.

5.  Click **OK**.

6.  In the configuration screen under connection, select **Advanced**.

7.  Fill in all the required connection parameters.

8.  For **Additional properties**, select **Edit inline**.

9.  Click the plus sign to add a new additional property.

10. Set **Key** to `key.deserializer` and **Value** to
    `io.confluent.kafka.serializers.KafkaAvroDeserializer`.

11. Repeat step 9 to add all the required Confluent Schema Registry properties.

In the **Configuration XML** window, check the complete confluent schema registry configuration
under the `<kafka:additional-property>` tags:

```xml
<kafka:consumer-config name="Apache_Kafka_Consumer_configuration” >
<kafka:consumer-plaintext-connection groupId="JenkinsTest">
<kafka:bootstrap-servers >
	<kafka:bootstrap-server value="localhost:9092" />
	</kafka:bootstrap-servers>
<kafka:additional-properties >
  <kafka:additional-property key="key.deserializer" value="’io.confluent.kafka.serializers.KafkaAvroDeserializer” />
    <kafka:additional-property key="value.deserializer value="io.confluent.kafka.serializers.KafkaAvroDeserializer" />
       <kafka:additional-property key="schema.registry.url" value="https://example.us-east-2.aws.confluent.cloud" />
      <kafka:additional-property key="basic.auth.credentials.source" value="USER_INFO" />
      <kafka:additional-property key="basic.auth.user.info" value="<put your credentials here>" />
       <kafka:additional-property key="auto.register.schemas" value="false" />
     <kafka:additional-property key="value.subject.name.strategy" value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
        </kafka:additional-properties>
        <kafka:topic-patterns >
		<kafka:topic-pattern value="InfraTopic" />
	    </kafka:topic-patterns>
        </kafka:consumer-plaintext-connection>
	    </kafka:consumer-config>
```

## Configure the Kafka Avro dependency in the POM File

In the POM file of the Mule app, configure the Kafka Avro dependency that contains the class to use
to serialize and deserialize. You must update the `<dependencies>`, `<plugin>`, and `<repository>`
sections of the POM file.

### Configure the <dependencies> Section

In the `<dependencies>` section, set `kafka-avro-serializer`:

```xml
<dependencies>
        <dependency>
            <groupId>io.confluent</groupId>
            <artifactId>kafka-avro-serializer</artifactId>
            <version>7.4.0</version>
        </dependency>
</dependencies>
```

### Configure the <plugin> Section

In the `<plugin>` section, set `kafka-avro-serializer` as a `<sharedLibrary>`:

```xml
<plugin>
	<groupId>org.mule.tools.maven</groupId>
	<artifactId>mule-maven-plugin</artifactId>
	<version>${mule.maven.plugin.version}</version>
		<extensions>true</extensions>
				<configuration>
					<additionalPluginDependencies>
						<plugin>
							<groupId>com.mulesoft.connectors</groupId>
							<artifactId>mule-kafka-connector</artifactId>
							<additionalDependencies>
								<dependency>
									<groupId>io.confluent</groupId>
									<artifactId>kafka-avro-serializer</artifactId>
									<version>7.6.1</version>
								</dependency>
							</additionalDependencies>
						</plugin>
					</additionalPluginDependencies>
					<sharedLibraries>
						<sharedLibrary>
							<groupId>io.confluent</groupId>
							<artifactId>kafka-avro-serializer</artifactId>
						</sharedLibrary>
					</sharedLibraries>
					<classifier>mule-application</classifier>
   </configuration>
</plugin>
```

Then, set the `avro-maven-plugin` plugin. This dependency from the `org.apache.avro` group is a
plugin for Apache Maven that facilitates handling Avro schema files in Java projects. The plugin
automatically generates Java classes from Avro schemas (.avsc), protocols (.avpr), and IDL files
(.avdl). This process simplifies development by eliminating the need to manually write Java classes
that represent Avro schemas, ensuring that the Java code is always synchronized with the Avro
schemas.

The `<sourceDirectory>` specifices the folder where the Avro schemas live, for example
`<sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>`.

```xml
<plugin>
<groupId>org.apache.avro</groupId>
	<artifactId>avro-maven-plugin</artifactId>
	<version>1.10.2</version>
	<executions>
		<execution>
			<phase>generate-sources</phase>
			<goals>
				<goal>schema</goal>
			</goals>
			<configuration>
            <sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>
			</configuration>
		</execution>
	</executions>
</plugin>
```

### Configure the <repository> Section

In the `<repository>` section, configure the repository of the dependency:

```xml
<repository>
            <id>confluent</id>
            <url>https://packages.confluent.io/maven/</url>
 </repository>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-examples)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=825d7a5ba5d2344a1e2b5a3a88383a5c98ef23658c080f5135700f54f2a034b1 url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-configure-confluent-example.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Integrate Confluent Schema Registry with Kafka Connector - Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to configure the Confluent Schema Registry using Kafka Connector.

Imagine you are developing a Mule 4 app that processes streaming data from various sources. To
ensure the data conforms to defined schemas and to manage schema evolution effectively, you
integrate Confluent Schema Registry with your Kafka Connector. This setup is crucial for developers
who need to enforce data integrity and compatibility across different versions of data producers and
consumers.

The configuration consists of two parts:

- Configuring the Confluent Schema Registry in the Kafka Connector connection using the **Additional
  Properties** field for the **Consumer** operation.

- Configuring the Kafka Avro dependency in the POM file of the Mule app

## Configure the Confluent Schema Registry in the Kafka Connector Connection

Use the **Additional Properties** field to configure the Confluent Schema Registry.

### Configure the Consumer Operation

To configure the **Consumer** operation in Anypoint Studio:

1.  Open your Mule project in Anypoint Studio and navigate to the **Global Elements** tab.

2.  Click **Create**.

3.  In the search box, type `kafka`.

4.  Select **Apache Kafka Consumer configuration**.

5.  Click **OK**.

6.  In the configuration screen under connection, select **Advanced**.

7.  Fill in all the required connection parameters.

8.  For **Additional properties**, select **Edit inline**.

9.  Click the plus sign to add a new additional property.

10. Set **Key** to `key.deserializer` and **Value** to
    `com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer`.

11. Repeat step 9 to add all the required Confluent Schema Registry properties.

Optionally, you can configure these system properties `maxCacheSize`, `maxCacheTTL` for the key
`mule.kafka.muleKafkaAvroDeserializer`:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Property</th><th>Description</th><th>Default</th></tr></thead><tbody><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.maxCacheSize</code></strong></p></td><td><div><div><p>The maximum number of schemas to store in cache.</p></div></div></td><td><div><div><p>200</p></div></div></td></tr><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.maxCacheTTL</code></strong></p></td><td><div><div><p>The time-to-live (TTL) in minutes that a schema remains in cache when not being used.</p></div></div></td><td><div><div><p>30 minutes</p></div></div></td></tr></tbody></table>

In the **Configuration XML** window, check the complete confluent schema registry configuration
under the `<kafka:additional-property>` tags:

```xml
<kafka:consumer-config name="Apache_Kafka_Consumer_configuration” >
<kafka:consumer-plaintext-connection groupId="JenkinsTest">
<kafka:bootstrap-servers >
	<kafka:bootstrap-server value="localhost:9092" />
	</kafka:bootstrap-servers>
<kafka:additional-properties >
  <kafka:additional-property key="key.deserializer" value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer" />
  <kafka:additional-property key="value.deserializer" value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer" />
       <kafka:additional-property key="schema.registry.url" value="https://example.us-east-2.aws.confluent.cloud" />
      <kafka:additional-property key="basic.auth.credentials.source" value="USER_INFO" />
      <kafka:additional-property key="basic.auth.user.info" value="<put your credentials here>" />
       <kafka:additional-property key="auto.register.schemas" value="false" />
     <kafka:additional-property key="value.subject.name.strategy" value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
        </kafka:additional-properties>
        <kafka:topic-patterns >
		<kafka:topic-pattern value="InfraTopic" />
	    </kafka:topic-patterns>
        </kafka:consumer-plaintext-connection>
	    </kafka:consumer-config>
```

## Configure the Kafka Avro dependency in the POM File

In the POM file of the Mule app, configure the Kafka Avro dependency that contains the class to use
to serialize and deserialize. You must update the `<dependencies>`, `<plugin>`, and `<repository>`
sections of the POM file.

### Configure the <dependencies> Section

In the `<dependencies>` section, set `kafka-avro-serializer`:

```xml
<dependencies>
        <dependency>
            <groupId>io.confluent</groupId>
            <artifactId>kafka-avro-serializer</artifactId>
            <version>7.4.0</version>
        </dependency>
</dependencies>
```

### Configure the <plugin> Section

In the `<plugin>` section, set `kafka-avro-serializer` as a `<sharedLibrary>`:

```xml
<plugin>
	<groupId>org.mule.tools.maven</groupId>
	<artifactId>mule-maven-plugin</artifactId>
	<version>${mule.maven.plugin.version}</version>
		<extensions>true</extensions>
				<configuration>
					<additionalPluginDependencies>
						<plugin>
							<groupId>com.mulesoft.connectors</groupId>
							<artifactId>mule-kafka-connector</artifactId>
							<additionalDependencies>
								<dependency>
									<groupId>io.confluent</groupId>
									<artifactId>kafka-avro-serializer</artifactId>
									<version>7.6.1</version>
								</dependency>
							</additionalDependencies>
						</plugin>
					</additionalPluginDependencies>
					<sharedLibraries>
						<sharedLibrary>
							<groupId>io.confluent</groupId>
							<artifactId>kafka-avro-serializer</artifactId>
						</sharedLibrary>
					</sharedLibraries>
					<classifier>mule-application</classifier>
   </configuration>
</plugin>
```

Then, set the `avro-maven-plugin` plugin. This dependency from the `org.apache.avro` group is a
plugin for Apache Maven that facilitates handling Avro schema files in Java projects. The plugin
automatically generates Java classes from Avro schemas (.avsc), protocols (.avpr), and IDL files
(.avdl). This process simplifies development by eliminating the need to manually write Java classes
that represent Avro schemas, ensuring that the Java code is always synchronized with the Avro
schemas.

The `<sourceDirectory>` specifices the folder where the Avro schemas live, for example
`<sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>`.

```xml
<plugin>
<groupId>org.apache.avro</groupId>
	<artifactId>avro-maven-plugin</artifactId>
	<version>1.10.2</version>
	<executions>
		<execution>
			<phase>generate-sources</phase>
			<goals>
				<goal>schema</goal>
			</goals>
			<configuration>
            <sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>
			</configuration>
		</execution>
	</executions>
</plugin>
```

### Configure the <repository> Section

In the `<repository>` section, configure the repository of the dependency:

```xml
<repository>
            <id>confluent</id>
            <url>https://packages.confluent.io/maven/</url>
 </repository>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-examples)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=c8e1071cec4df3a24e7e75adc8ec72f361cb2bc1b722757f168143108738f753 url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-configure-confluent-example.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Integrate Confluent Schema Registry with Kafka Connector - Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to configure the Confluent Schema Registry using Kafka Connector.

Imagine you are developing a Mule 4 app that processes streaming data from various sources. To
ensure the data conforms to defined schemas and to manage schema evolution effectively, you
integrate Confluent Schema Registry with your Kafka Connector. This setup is crucial for developers
who need to enforce data integrity and compatibility across different versions of data producers and
consumers.

The configuration consists of two parts:

- Configuring the Confluent Schema Registry in the Kafka Connector connection using the **Additional
  Properties** field for the **Consumer** operation.

- Configuring the Kafka Avro dependency in the POM file of the Mule app

## Configure the Confluent Schema Registry in the Kafka Connector Connection

Use the **Additional Properties** field to configure the Confluent Schema Registry.

### Configure the Consumer Operation

To configure the **Consumer** operation in Anypoint Studio:

1.  Open your Mule project in Anypoint Studio and navigate to the **Global Elements** tab.

2.  Click **Create**.

3.  In the search box, type `kafka`.

4.  Select **Apache Kafka Consumer configuration**.

5.  Click **OK**.

6.  In the configuration screen under connection, select **Advanced**.

7.  Fill in all the required connection parameters.

8.  For **Additional properties**, select **Edit inline**.

9.  Click the plus sign to add a new additional property.

10. Set **Key** to `key.deserializer` and **Value** to
    `com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer`.

11. Repeat step 9 to add all the required Confluent Schema Registry properties.

Optionally, you can configure these system properties `maxCacheSize`, `maxCacheTTL` for the key
`mule.kafka.muleKafkaAvroDeserializer`:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Property</th><th>Description</th><th>Default</th></tr></thead><tbody><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.maxCacheSize</code></strong></p></td><td><div><div><p>The maximum number of schemas to store in cache.</p></div></div></td><td><div><div><p>200</p></div></div></td></tr><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.maxCacheTTL</code></strong></p></td><td><div><div><p>The time-to-live (TTL) in minutes that a schema remains in cache when not being used.</p></div></div></td><td><div><div><p>30 minutes</p></div></div></td></tr></tbody></table>

In the **Configuration XML** window, check the complete confluent schema registry configuration
under the `<kafka:additional-property>` tags:

```xml
<kafka:consumer-config name="Apache_Kafka_Consumer_configuration” >
<kafka:consumer-plaintext-connection groupId="JenkinsTest">
<kafka:bootstrap-servers >
	<kafka:bootstrap-server value="localhost:9092" />
	</kafka:bootstrap-servers>
<kafka:additional-properties >
  <kafka:additional-property key="key.deserializer" value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer" />
  <kafka:additional-property key="value.deserializer" value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer" />
       <kafka:additional-property key="schema.registry.url" value="https://example.us-east-2.aws.confluent.cloud" />
      <kafka:additional-property key="basic.auth.credentials.source" value="USER_INFO" />
      <kafka:additional-property key="basic.auth.user.info" value="<put your credentials here>" />
       <kafka:additional-property key="auto.register.schemas" value="false" />
     <kafka:additional-property key="value.subject.name.strategy" value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
        </kafka:additional-properties>
        <kafka:topic-patterns >
		<kafka:topic-pattern value="InfraTopic" />
	    </kafka:topic-patterns>
        </kafka:consumer-plaintext-connection>
	    </kafka:consumer-config>
```

## Configure the Kafka Avro dependency in the POM File

In the POM file of the Mule app, configure the Kafka Avro dependency that contains the class to use
to serialize and deserialize. You must update the `<dependencies>`, `<plugin>`, and `<repository>`
sections of the POM file.

### Configure the <dependencies> Section

In the `<dependencies>` section, set `kafka-avro-serializer`:

```xml
<dependencies>
        <dependency>
            <groupId>io.confluent</groupId>
            <artifactId>kafka-avro-serializer</artifactId>
            <version>7.4.0</version>
        </dependency>
</dependencies>
```

### Configure the <plugin> Section

In the `<plugin>` section, set `kafka-avro-serializer` as a `<sharedLibrary>`:

```xml
<plugin>
	<groupId>org.mule.tools.maven</groupId>
	<artifactId>mule-maven-plugin</artifactId>
	<version>${mule.maven.plugin.version}</version>
		<extensions>true</extensions>
				<configuration>
					<additionalPluginDependencies>
						<plugin>
							<groupId>com.mulesoft.connectors</groupId>
							<artifactId>mule-kafka-connector</artifactId>
							<additionalDependencies>
								<dependency>
									<groupId>io.confluent</groupId>
									<artifactId>kafka-avro-serializer</artifactId>
									<version>7.6.1</version>
								</dependency>
							</additionalDependencies>
						</plugin>
					</additionalPluginDependencies>
					<sharedLibraries>
						<sharedLibrary>
							<groupId>io.confluent</groupId>
							<artifactId>kafka-avro-serializer</artifactId>
						</sharedLibrary>
					</sharedLibraries>
					<classifier>mule-application</classifier>
   </configuration>
</plugin>
```

Then, set the `avro-maven-plugin` plugin. This dependency from the `org.apache.avro` group is a
plugin for Apache Maven that facilitates handling Avro schema files in Java projects. The plugin
automatically generates Java classes from Avro schemas (.avsc), protocols (.avpr), and IDL files
(.avdl). This process simplifies development by eliminating the need to manually write Java classes
that represent Avro schemas, ensuring that the Java code is always synchronized with the Avro
schemas.

The `<sourceDirectory>` specifices the folder where the Avro schemas live, for example
`<sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>`.

```xml
<plugin>
<groupId>org.apache.avro</groupId>
	<artifactId>avro-maven-plugin</artifactId>
	<version>1.10.2</version>
	<executions>
		<execution>
			<phase>generate-sources</phase>
			<goals>
				<goal>schema</goal>
			</goals>
			<configuration>
            <sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>
			</configuration>
		</execution>
	</executions>
</plugin>
```

### Configure the <repository> Section

In the `<repository>` section, configure the repository of the dependency:

```xml
<repository>
            <id>confluent</id>
            <url>https://packages.confluent.io/maven/</url>
 </repository>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-examples)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=4126da938c6e92327fd05c920b8ea8c9ad1d0420568f2e6fcd5e4e06c95fbd24 url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-configure-confluent-example.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Integrate Confluent Schema Registry with Kafka Connector - Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to configure the Confluent Schema Registry using Kafka Connector.

Imagine you are developing a Mule 4 app that processes streaming data from various sources. To
ensure the data conforms to defined schemas and to manage schema evolution effectively, you
integrate Confluent Schema Registry with your Kafka Connector. This setup is crucial for developers
who need to enforce data integrity and compatibility across different versions of data producers and
consumers.

The configuration consists of two parts:

- Configuring the Confluent Schema Registry in the Kafka Connector connection using the **Additional
  Properties** field for the **Consumer** operation.

- Configuring the Kafka Avro dependency in the POM file of the Mule app

## Configure the Confluent Schema Registry in the Kafka Connector Connection

Use the **Additional Properties** field to configure the Confluent Schema Registry.

### Configure the Consumer Operation

To configure the **Consumer** operation in Anypoint Studio:

1.  Open your Mule project in Anypoint Studio and navigate to the **Global Elements** tab.

2.  Click **Create**.

3.  In the search box, type `kafka`.

4.  Select **Apache Kafka Consumer configuration**.

5.  Click **OK**.

6.  In the configuration screen under connection, select **Advanced**.

7.  Fill in all the required connection parameters.

8.  For **Additional properties**, select **Edit inline**.

9.  Click the plus sign to add a new additional property.

10. Set **Key** to `key.deserializer` and **Value** to
    `com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer`.

11. Repeat step 9 to add all the required Confluent Schema Registry properties.

Optionally, you can configure these system properties `maxCacheSize`, `maxCacheTTL` for the key
`mule.kafka.muleKafkaAvroDeserializer`:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Property</th><th>Description</th><th>Default</th></tr></thead><tbody><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.maxCacheSize</code></strong></p></td><td><div><div><p>The maximum number of schemas to store in cache.</p></div></div></td><td><div><div><p>200</p></div></div></td></tr><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.maxCacheTTL</code></strong></p></td><td><div><div><p>The time-to-live (TTL) in minutes that a schema remains in cache when not being used.</p></div></div></td><td><div><div><p>30 minutes</p></div></div></td></tr></tbody></table>

In the **Configuration XML** window, check the complete confluent schema registry configuration
under the `<kafka:additional-property>` tags:

```xml
<kafka:consumer-config name="Apache_Kafka_Consumer_configuration” >
<kafka:consumer-plaintext-connection groupId="JenkinsTest">
<kafka:bootstrap-servers >
	<kafka:bootstrap-server value="localhost:9092" />
	</kafka:bootstrap-servers>
<kafka:additional-properties >
  <kafka:additional-property key="key.deserializer" value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer" />
  <kafka:additional-property key="value.deserializer" value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer" />
       <kafka:additional-property key="schema.registry.url" value="https://example.us-east-2.aws.confluent.cloud" />
      <kafka:additional-property key="basic.auth.credentials.source" value="USER_INFO" />
      <kafka:additional-property key="basic.auth.user.info" value="<put your credentials here>" />
       <kafka:additional-property key="auto.register.schemas" value="false" />
     <kafka:additional-property key="value.subject.name.strategy" value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
        </kafka:additional-properties>
        <kafka:topic-patterns >
		<kafka:topic-pattern value="InfraTopic" />
	    </kafka:topic-patterns>
        </kafka:consumer-plaintext-connection>
	    </kafka:consumer-config>
```

## Configure the Kafka Avro dependency in the POM File

In the POM file of the Mule app, configure the Kafka Avro dependency that contains the class to use
to serialize and deserialize. You must update the `<dependencies>`, `<plugin>`, and `<repository>`
sections of the POM file.

### Configure the <dependencies> Section

In the `<dependencies>` section, set `kafka-avro-serializer`:

```xml
<dependencies>
        <dependency>
            <groupId>io.confluent</groupId>
            <artifactId>kafka-avro-serializer</artifactId>
            <version>7.4.0</version>
        </dependency>
</dependencies>
```

### Configure the <plugin> Section

In the `<plugin>` section, set `kafka-avro-serializer` as a `<sharedLibrary>`:

```xml
<plugin>
	<groupId>org.mule.tools.maven</groupId>
	<artifactId>mule-maven-plugin</artifactId>
	<version>${mule.maven.plugin.version}</version>
		<extensions>true</extensions>
				<configuration>
					<additionalPluginDependencies>
						<plugin>
							<groupId>com.mulesoft.connectors</groupId>
							<artifactId>mule-kafka-connector</artifactId>
							<additionalDependencies>
								<dependency>
									<groupId>io.confluent</groupId>
									<artifactId>kafka-avro-serializer</artifactId>
									<version>7.6.1</version>
								</dependency>
							</additionalDependencies>
						</plugin>
					</additionalPluginDependencies>
					<sharedLibraries>
						<sharedLibrary>
							<groupId>io.confluent</groupId>
							<artifactId>kafka-avro-serializer</artifactId>
						</sharedLibrary>
					</sharedLibraries>
					<classifier>mule-application</classifier>
   </configuration>
</plugin>
```

Then, set the `avro-maven-plugin` plugin. This dependency from the `org.apache.avro` group is a
plugin for Apache Maven that facilitates handling Avro schema files in Java projects. The plugin
automatically generates Java classes from Avro schemas (.avsc), protocols (.avpr), and IDL files
(.avdl). This process simplifies development by eliminating the need to manually write Java classes
that represent Avro schemas, ensuring that the Java code is always synchronized with the Avro
schemas.

The `<sourceDirectory>` specifices the folder where the Avro schemas live, for example
`<sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>`.

```xml
<plugin>
<groupId>org.apache.avro</groupId>
	<artifactId>avro-maven-plugin</artifactId>
	<version>1.10.2</version>
	<executions>
		<execution>
			<phase>generate-sources</phase>
			<goals>
				<goal>schema</goal>
			</goals>
			<configuration>
            <sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>
			</configuration>
		</execution>
	</executions>
</plugin>
```

### Configure the <repository> Section

In the `<repository>` section, configure the repository of the dependency:

```xml
<repository>
            <id>confluent</id>
            <url>https://packages.confluent.io/maven/</url>
 </repository>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-examples)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=3d3848e03d5fc31bf373d807ea32663954302537d67f5ec2c4f7ffae375aef81 url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-configure-confluent-example.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Integrate Confluent Schema Registry with Kafka Connector - Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to configure the Confluent Schema Registry using Kafka Connector.

Imagine you are developing a Mule 4 app that processes streaming data from various sources. To
ensure the data conforms to defined schemas and to manage schema evolution effectively, you
integrate Confluent Schema Registry with your Kafka Connector. This setup is crucial for developers
who need to enforce data integrity and compatibility across different versions of data producers and
consumers.

The configuration consists of two parts:

- Configuring the Confluent Schema Registry in the Kafka Connector connection using the **Additional
  Properties** field for the **Consumer** operation.

- Configuring the Kafka Avro dependency in the POM file of the Mule app

## Configure the Confluent Schema Registry in the Kafka Connector Connection

Use the **Additional Properties** field to configure the Confluent Schema Registry.

### Configure the Consumer Operation

To configure the **Consumer** operation in Anypoint Studio:

1.  Open your Mule project in Anypoint Studio and navigate to the **Global Elements** tab.

2.  Click **Create**.

3.  In the search box, type `kafka`.

4.  Select **Apache Kafka Consumer configuration**.

5.  Click **OK**.

6.  In the configuration screen under connection, select **Advanced**.

7.  Fill in all the required connection parameters.

8.  For **Additional properties**, select **Edit inline**.

9.  Click the plus sign to add a new additional property.

10. Set **Key** to `key.deserializer` and **Value** to
    `com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer`.

11. Repeat step 9 to add all the required Confluent Schema Registry properties.

Optionally, you can configure the system properties `maxCacheSize`, `maxCacheTTL`, or
`useLogicalTypeAwareRenderer` for the key `mule.kafka.muleKafkaAvroDeserializer`:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Property</th><th>Description</th><th>Default</th></tr></thead><tbody><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.maxCacheSize</code></strong></p></td><td><div><div><p>The maximum number of schemas to store in cache.</p></div></div></td><td><div><div><p>200</p></div></div></td></tr><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.maxCacheTTL</code></strong></p></td><td><div><div><p>The time-to-live (TTL) in minutes that a schema remains in cache when not being used.</p></div></div></td><td><div><div><p>30 minutes</p></div></div></td></tr><tr><td><p><strong><code>mule.kafka.muleKafkaAvroDeserializer.useLogicalTypeAwareRenderer</code></strong></p></td><td><div><div><p>When set to <code>true</code>, the deserializer represents each Avro logical type field according to its semantic value rather than its physical wire representation. For example, a decimal field is represented as an exact numeric string such as "9.99" instead of as raw bytes and a scale, and date, time, or timestamp fields are represented as ISO-8601 strings. Set this to <code>false</code> to maintain the legacy physical type representation and ensure backward compatibility.</p></div></div></td><td><div><div><p>false</p></div></div></td></tr></tbody></table>

In the **Configuration XML** window, check the complete confluent schema registry configuration
under the `<kafka:additional-property>` tags:

```xml
<kafka:consumer-config name="Apache_Kafka_Consumer_configuration” >
<kafka:consumer-plaintext-connection groupId="JenkinsTest">
<kafka:bootstrap-servers >
	<kafka:bootstrap-server value="localhost:9092" />
	</kafka:bootstrap-servers>
<kafka:additional-properties >
  <kafka:additional-property key="key.deserializer" value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer" />
  <kafka:additional-property key="value.deserializer" value="com.mulesoft.connectors.kafka.internal.model.serializer.MuleKafkaAvroDeserializer" />
       <kafka:additional-property key="schema.registry.url" value="https://example.us-east-2.aws.confluent.cloud" />
      <kafka:additional-property key="basic.auth.credentials.source" value="USER_INFO" />
      <kafka:additional-property key="basic.auth.user.info" value="<put your credentials here>" />
       <kafka:additional-property key="auto.register.schemas" value="false" />
     <kafka:additional-property key="value.subject.name.strategy" value="io.confluent.kafka.serializers.subject.TopicNameStrategy" />
        </kafka:additional-properties>
        <kafka:topic-patterns >
		<kafka:topic-pattern value="InfraTopic" />
	    </kafka:topic-patterns>
        </kafka:consumer-plaintext-connection>
	    </kafka:consumer-config>
```

## Configure the Kafka Avro dependency in the POM File

In the POM file of the Mule app, configure the Kafka Avro dependency that contains the class to use
to serialize and deserialize. You must update the `<dependencies>`, `<plugin>`, and `<repository>`
sections of the POM file.

### Configure the <dependencies> Section

In the `<dependencies>` section, set `kafka-avro-serializer`:

```xml
<dependencies>
        <dependency>
            <groupId>io.confluent</groupId>
            <artifactId>kafka-avro-serializer</artifactId>
            <version>7.4.0</version>
        </dependency>
</dependencies>
```

### Configure the <plugin> Section

In the `<plugin>` section, set `kafka-avro-serializer` as a `<sharedLibrary>`:

```xml
<plugin>
	<groupId>org.mule.tools.maven</groupId>
	<artifactId>mule-maven-plugin</artifactId>
	<version>${mule.maven.plugin.version}</version>
		<extensions>true</extensions>
				<configuration>
					<additionalPluginDependencies>
						<plugin>
							<groupId>com.mulesoft.connectors</groupId>
							<artifactId>mule-kafka-connector</artifactId>
							<additionalDependencies>
								<dependency>
									<groupId>io.confluent</groupId>
									<artifactId>kafka-avro-serializer</artifactId>
									<version>7.6.1</version>
								</dependency>
							</additionalDependencies>
						</plugin>
					</additionalPluginDependencies>
					<sharedLibraries>
						<sharedLibrary>
							<groupId>io.confluent</groupId>
							<artifactId>kafka-avro-serializer</artifactId>
						</sharedLibrary>
					</sharedLibraries>
					<classifier>mule-application</classifier>
   </configuration>
</plugin>
```

Then, set the `avro-maven-plugin` plugin. This dependency from the `org.apache.avro` group is a
plugin for Apache Maven that facilitates handling Avro schema files in Java projects. The plugin
automatically generates Java classes from Avro schemas (.avsc), protocols (.avpr), and IDL files
(.avdl). This process simplifies development by eliminating the need to manually write Java classes
that represent Avro schemas, ensuring that the Java code is always synchronized with the Avro
schemas.

The `<sourceDirectory>` specifices the folder where the Avro schemas live, for example
`<sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>`.

```xml
<plugin>
<groupId>org.apache.avro</groupId>
	<artifactId>avro-maven-plugin</artifactId>
	<version>1.10.2</version>
	<executions>
		<execution>
			<phase>generate-sources</phase>
			<goals>
				<goal>schema</goal>
			</goals>
			<configuration>
            <sourceDirectory>${project.basedir}/PATH_TO_SCHEMAS</sourceDirectory>
			</configuration>
		</execution>
	</executions>
</plugin>
```

### Configure the <repository> Section

In the `<repository>` section, configure the repository of the dependency:

```xml
<repository>
            <id>confluent</id>
            <url>https://packages.confluent.io/maven/</url>
 </repository>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-examples)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=c4687f475fe60b9219c3e61b6546418c16b2145fa2f7a917fe1fe6bdfa445dcd url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-publish-consume-example.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Publish and Then Consume a Topic with Kafka Connector

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This example shows how to use two Apache Kafka Connector operations, **Publish** and **Consume**, to
publish a message to Apache Kafka and then retrieve it. The example contains two flows:

- The first flow is the Producer flow, which publishes a message to Apache Kafka.

- The second flow is the Consumer flow, which consumes a message from Apache Kafka.

![Apache Kafka Connector Producer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-producer-studio-flow.png)

![Apache Kafka Connector Consumer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-consumer-studio-flow.png)

## Configure the First Flow

Configure the first flow that publishes a message to Apache Kafka. Creating the first flow involves
configuring a **Listener** component, a **Logger** component, a **Publish** operation, and a **Set
Payload** transformer.

### Configure the HTTP Listener

Configure the **Listener** component to initiate a Mule flow when a call is made to the
`/pushMessage` path:

1.  Create a new Mule project in Studio.

2.  From the **Mule Palette** view, select **HTTP** and drag the **Listener** component to the
    canvas.

3.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

4.  Accept the defaults.

5.  In the properties window, set the **Path** field value to `/pushMessage`.

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>#["Message: '" payload.message "' is going to be published to topic: '" payload.topic "'."]</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-logger-config-publish.png)

### Add the Publish Operation

Add the **Publish** operation to publish a message to the specified Kafka topic:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Publish** operation to
    the right of **Logger**.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector operation.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr><tr><td><p>Topic</p></td><td><p><code>\#[payload.topic]</code></p></td></tr><tr><td><p>Key</p></td><td><p><code>#[now()]</code></p></td></tr><tr><td><p>Message</p></td><td><p><code>payload</code></p></td></tr></tbody></table>

    The following image shows an example of the **Publish** configuration in the properties window:

    ![Publish properties window configuration](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-publish.png)

### Add the Set Payload Transformer

Add the **Set Payload** transformer to push the response builder:

1.  From the **Mule Palette** view, select **Core** and drag the **Set Payload** transformer to the
    right of **Publish**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the transformer, such as <code>Push response builder</code>.</p></td></tr><tr><td><p>Value</p></td><td><p><code>Message successfully sent to Apache Kafka topic.</code></p></td></tr></tbody></table>

    The following image shows an example of the **Set Payload** configuration in the properties
    window:

    ![Set Payload properties window configuration](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-set-payload.png)

## Configure the Second Flow

Configure the second flow that consumes a message from Apache Kafka. Creating the second flow
involves configuring a **Message listener** source and a **Logger** component.

### Add the Message Listener Source

Add the **Message listener** source to consume a message endpoint:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Message listener** source
    to the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish.**

    3.  In the **Group ID** field, enter `${consumer.groupId}`.

    4.  In the **Topic Subscription Patterns** field, select **Edit inline** and then click the
        green plus sign.

    5.  Enter the value `${topic1}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector source.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr></tbody></table>

    The following image shows an example of the **Message listener** configuration in the properties
    window:

    ![Message listener properties window configuration](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-message-listener-config.png)

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Message listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>"New message arrived: " payload ", key:" attributes.key ", partition:" attributes.partition ", offset:" ++ attributes.offset</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-logger-config-consume.png)

## XML for This Example

Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule
app:

```xml
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:Kafka="http://www.mulesoft.org/schema/mule/Kafka"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:spring="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/http
  http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
  http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans-current.xsd
	http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
  <configuration-properties file="mule-app.properties">
	</configuration-properties>
  <http:listener-config name="HTTP_Listener_config"
    doc:name="HTTP Listener config"  >
  <http:listener-connection host="0.0.0.0" port="8081" />
  </http:listener-config>

  <kafka:consumer-config name="Apache_Kafka_Consumer_configuration"
 	  doc:name="Apache Kafka Consumer configuration" >
	  <kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  <kafka:topic-patterns >
	    <kafka:topic-pattern value='${topic1}
	    &lt;kafka:topic-pattern value="topic-1" /&gt;
	    &lt;kafka:topic-pattern value="topic-2" /&gt;
	    &lt;/kafka:topic-patterns&gt;]' />
	  </kafka:topic-patterns>
	  </kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<kafka:producer-config name="Apache_Kafka_Producer_configuration"
	  doc:name="Apache Kafka Producer configuration" >
	  <kafka:producer-plaintext-connection >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  </kafka:producer-plaintext-connection>
	  </kafka:producer-config>
	<kafka:consumer-config name="Apache_Kafka_Consumer_configuration1" doc:name="Apache Kafka Consumer configuration" >
		<kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
			<kafka:bootstrap-servers >
				<kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
			</kafka:bootstrap-servers>
			<kafka:topic-patterns >
				<kafka:topic-pattern value="${config.topics}" />
			</kafka:topic-patterns>
		</kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<flow name="Producer-Flow" >
		<http:listener doc:name="Push message endpoint" config-ref="HTTP_Listener_config" path="/pushMessage" />
		<logger level="INFO" doc:name="Logger" message="&amp;quot;Message: '&amp;quot; ++ payload.message ++ &amp;quot;' is going to be published to topic: '&amp;quot; ++ payload.topic ++ &amp;quot;'.&amp;quot;" />
		<kafka:publish doc:name="Producer" topic="#[payload.topic]" key="#[now()]" config-ref="Apache_Kafka_Producer_configuration" />
		<set-payload value="Message successfully sent to Apache Kafka topic." doc:name="Push response builder" />
	</flow>
	<flow name="Consumer-Flow" >
		<kafka:message-listener doc:name="Consume message endpoint" config-ref="Apache_Kafka_Consumer_configuration"/>
		<logger level="INFO" doc:name="Logger" message="'New message arrived: ' ++ payload ++ &amp;quot;, key:&amp;quot; ++ attributes.key ++ &amp;quot;, partition:&amp;quot; ++ attributes.partition ++ &amp;quot;, offset:&amp;quot; ++ attributes.offset"/>
	</flow>
</mule>
```

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=217d57c273da400a28021069b0fdb465cfe46ca5189e34af123ac3fba73f1a5f url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-publish-consume-example.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Publish and Then Consume a Topic with Kafka Connector

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This example shows how to use two Apache Kafka Connector operations, **Publish** and **Consume**, to
publish a message to Apache Kafka and then retrieve it. The example contains two flows:

- The first flow is the Producer flow, which publishes a message to Apache Kafka.

- The second flow is the Consumer flow, which consumes a message from Apache Kafka.

![Apache Kafka Connector Producer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-producer-studio-flow.png)

![Apache Kafka Connector Consumer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-consumer-studio-flow.png)

## Configure the First Flow

Configure the first flow that publishes a message to Apache Kafka. Creating the first flow involves
configuring a **Listener** component, a **Logger** component, a **Publish** operation, and a **Set
Payload** transformer.

### Configure the HTTP Listener

Configure the **Listener** component to initiate a Mule flow when a call is made to the
`/pushMessage` path:

1.  Create a new Mule project in Studio.

2.  From the **Mule Palette** view, select **HTTP** and drag the **Listener** component to the
    canvas.

3.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

4.  Accept the defaults.

5.  In the properties window, set the **Path** field value to `/pushMessage`.

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>#["Message: '" payload.message "' is going to be published to topic: '" payload.topic "'."]</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-logger-config-publish.png)

### Add the Publish Operation

Add the **Publish** operation to publish a message to the specified Kafka topic:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Publish** operation to
    the right of **Logger**.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector operation.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr><tr><td><p>Topic</p></td><td><p><code>\#[payload.topic]</code></p></td></tr><tr><td><p>Key</p></td><td><p><code>#[now()]</code></p></td></tr><tr><td><p>Message</p></td><td><p><code>payload</code></p></td></tr></tbody></table>

    The following image shows an example of the **Publish** configuration in the properties window:

    ![Publish properties window configuration](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-publish.png)

### Add the Set Payload Transformer

Add the **Set Payload** transformer to push the response builder:

1.  From the **Mule Palette** view, select **Core** and drag the **Set Payload** transformer to the
    right of **Publish**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the transformer, such as <code>Push response builder</code>.</p></td></tr><tr><td><p>Value</p></td><td><p><code>Message successfully sent to Apache Kafka topic.</code></p></td></tr></tbody></table>

    The following image shows an example of the **Set Payload** configuration in the properties
    window:

    ![Set Payload properties window configuration](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-set-payload.png)

## Configure the Second Flow

Configure the second flow that consumes a message from Apache Kafka. Creating the second flow
involves configuring a **Message listener** source and a **Logger** component.

### Add the Message Listener Source

Add the **Message listener** source to consume a message endpoint:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Message listener** source
    to the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish.**

    3.  In the **Group ID** field, enter `${consumer.groupId}`.

    4.  In the **Topic Subscription Patterns** field, select **Edit inline** and then click the
        green plus sign.

    5.  Enter the value `${topic1}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector source.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr></tbody></table>

    The following image shows an example of the **Message listener** configuration in the properties
    window:

    ![Message listener properties window configuration](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-message-listener-config.png)

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Message listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>"New message arrived: " payload ", key:" attributes.key ", partition:" attributes.partition ", offset:" ++ attributes.offset</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-logger-config-consume.png)

## XML for This Example

Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule
app:

```xml
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:Kafka="http://www.mulesoft.org/schema/mule/Kafka"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:spring="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/http
  http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
  http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans-current.xsd
	http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
  <configuration-properties file="mule-app.properties">
	</configuration-properties>
  <http:listener-config name="HTTP_Listener_config"
    doc:name="HTTP Listener config"  >
  <http:listener-connection host="0.0.0.0" port="8081" />
  </http:listener-config>

  <kafka:consumer-config name="Apache_Kafka_Consumer_configuration"
 	  doc:name="Apache Kafka Consumer configuration" >
	  <kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  <kafka:topic-patterns >
	    <kafka:topic-pattern value='${topic1}
	    &lt;kafka:topic-pattern value="topic-1" /&gt;
	    &lt;kafka:topic-pattern value="topic-2" /&gt;
	    &lt;/kafka:topic-patterns&gt;]' />
	  </kafka:topic-patterns>
	  </kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<kafka:producer-config name="Apache_Kafka_Producer_configuration"
	  doc:name="Apache Kafka Producer configuration" >
	  <kafka:producer-plaintext-connection >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  </kafka:producer-plaintext-connection>
	  </kafka:producer-config>
	<kafka:consumer-config name="Apache_Kafka_Consumer_configuration1" doc:name="Apache Kafka Consumer configuration" >
		<kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
			<kafka:bootstrap-servers >
				<kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
			</kafka:bootstrap-servers>
			<kafka:topic-patterns >
				<kafka:topic-pattern value="${config.topics}" />
			</kafka:topic-patterns>
		</kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<flow name="Producer-Flow" >
		<http:listener doc:name="Push message endpoint" config-ref="HTTP_Listener_config" path="/pushMessage" />
		<logger level="INFO" doc:name="Logger" message="&amp;quot;Message: '&amp;quot; ++ payload.message ++ &amp;quot;' is going to be published to topic: '&amp;quot; ++ payload.topic ++ &amp;quot;'.&amp;quot;" />
		<kafka:publish doc:name="Producer" topic="#[payload.topic]" key="#[now()]" config-ref="Apache_Kafka_Producer_configuration" />
		<set-payload value="Message successfully sent to Apache Kafka topic." doc:name="Push response builder" />
	</flow>
	<flow name="Consumer-Flow" >
		<kafka:message-listener doc:name="Consume message endpoint" config-ref="Apache_Kafka_Consumer_configuration"/>
		<logger level="INFO" doc:name="Logger" message="'New message arrived: ' ++ payload ++ &amp;quot;, key:&amp;quot; ++ attributes.key ++ &amp;quot;, partition:&amp;quot; ++ attributes.partition ++ &amp;quot;, offset:&amp;quot; ++ attributes.offset"/>
	</flow>
</mule>
```

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=32fe8c8afbc7b1864cbb7f542d521e48335a896a169aee8982c7470c1ac9ea89 url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-publish-consume-example.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Publish and Then Consume a Topic with Kafka Connector

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This example shows how to use two Apache Kafka Connector operations, **Publish** and **Consume**, to
publish a message to Apache Kafka and then retrieve it. The example contains two flows:

- The first flow is the Producer flow, which publishes a message to Apache Kafka.

- The second flow is the Consumer flow, which consumes a message from Apache Kafka.

![Apache Kafka Connector Producer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-producer-studio-flow.png)

![Apache Kafka Connector Consumer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-consumer-studio-flow.png)

## Configure the First Flow

Configure the first flow that publishes a message to Apache Kafka. Creating the first flow involves
configuring a **Listener** component, a **Logger** component, a **Publish** operation, and a **Set
Payload** transformer.

### Configure the HTTP Listener

Configure the **Listener** component to initiate a Mule flow when a call is made to the
`/pushMessage` path:

1.  Create a new Mule project in Studio.

2.  From the **Mule Palette** view, select **HTTP** and drag the **Listener** component to the
    canvas.

3.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

4.  Accept the defaults.

5.  In the properties window, set the **Path** field value to `/pushMessage`.

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>#["Message: '" payload.message "' is going to be published to topic: '" payload.topic "'."]</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-logger-config-publish.png)

### Add the Publish Operation

Add the **Publish** operation to publish a message to the specified Kafka topic:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Publish** operation to
    the right of **Logger**.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector operation.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr><tr><td><p>Topic</p></td><td><p><code>\#[payload.topic]</code></p></td></tr><tr><td><p>Key</p></td><td><p><code>#[now()]</code></p></td></tr><tr><td><p>Message</p></td><td><p><code>payload</code></p></td></tr></tbody></table>

    The following image shows an example of the **Publish** configuration in the properties window:

    ![Publish properties window configuration](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-publish.png)

### Add the Set Payload Transformer

Add the **Set Payload** transformer to push the response builder:

1.  From the **Mule Palette** view, select **Core** and drag the **Set Payload** transformer to the
    right of **Publish**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the transformer, such as <code>Push response builder</code>.</p></td></tr><tr><td><p>Value</p></td><td><p><code>Message successfully sent to Apache Kafka topic.</code></p></td></tr></tbody></table>

    The following image shows an example of the **Set Payload** configuration in the properties
    window:

    ![Set Payload properties window configuration](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-set-payload.png)

## Configure the Second Flow

Configure the second flow that consumes a message from Apache Kafka. Creating the second flow
involves configuring a **Message listener** source and a **Logger** component.

### Add the Message Listener Source

Add the **Message listener** source to consume a message endpoint:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Message listener** source
    to the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish.**

    3.  In the **Group ID** field, enter `${consumer.groupId}`.

    4.  In the **Topic Subscription Patterns** field, select **Edit inline** and then click the
        green plus sign.

    5.  Enter the value `${topic1}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector source.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr></tbody></table>

    The following image shows an example of the **Message listener** configuration in the properties
    window:

    ![Message listener properties window configuration](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-message-listener-config.png)

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Message listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>"New message arrived: " payload ", key:" attributes.key ", partition:" attributes.partition ", offset:" ++ attributes.offset</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-logger-config-consume.png)

## XML for This Example

Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule
app:

```xml
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:Kafka="http://www.mulesoft.org/schema/mule/Kafka"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:spring="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/http
  http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
  http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans-current.xsd
	http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
  <configuration-properties file="mule-app.properties">
	</configuration-properties>
  <http:listener-config name="HTTP_Listener_config"
    doc:name="HTTP Listener config"  >
  <http:listener-connection host="0.0.0.0" port="8081" />
  </http:listener-config>

  <kafka:consumer-config name="Apache_Kafka_Consumer_configuration"
 	  doc:name="Apache Kafka Consumer configuration" >
	  <kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  <kafka:topic-patterns >
	    <kafka:topic-pattern value='${topic1}
	    &lt;kafka:topic-pattern value="topic-1" /&gt;
	    &lt;kafka:topic-pattern value="topic-2" /&gt;
	    &lt;/kafka:topic-patterns&gt;]' />
	  </kafka:topic-patterns>
	  </kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<kafka:producer-config name="Apache_Kafka_Producer_configuration"
	  doc:name="Apache Kafka Producer configuration" >
	  <kafka:producer-plaintext-connection >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  </kafka:producer-plaintext-connection>
	  </kafka:producer-config>
	<kafka:consumer-config name="Apache_Kafka_Consumer_configuration1" doc:name="Apache Kafka Consumer configuration" >
		<kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
			<kafka:bootstrap-servers >
				<kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
			</kafka:bootstrap-servers>
			<kafka:topic-patterns >
				<kafka:topic-pattern value="${config.topics}" />
			</kafka:topic-patterns>
		</kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<flow name="Producer-Flow" >
		<http:listener doc:name="Push message endpoint" config-ref="HTTP_Listener_config" path="/pushMessage" />
		<logger level="INFO" doc:name="Logger" message="&amp;quot;Message: '&amp;quot; ++ payload.message ++ &amp;quot;' is going to be published to topic: '&amp;quot; ++ payload.topic ++ &amp;quot;'.&amp;quot;" />
		<kafka:publish doc:name="Producer" topic="#[payload.topic]" key="#[now()]" config-ref="Apache_Kafka_Producer_configuration" />
		<set-payload value="Message successfully sent to Apache Kafka topic." doc:name="Push response builder" />
	</flow>
	<flow name="Consumer-Flow" >
		<kafka:message-listener doc:name="Consume message endpoint" config-ref="Apache_Kafka_Consumer_configuration"/>
		<logger level="INFO" doc:name="Logger" message="'New message arrived: ' ++ payload ++ &amp;quot;, key:&amp;quot; ++ attributes.key ++ &amp;quot;, partition:&amp;quot; ++ attributes.partition ++ &amp;quot;, offset:&amp;quot; ++ attributes.offset"/>
	</flow>
</mule>
```

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=b697b552eca82f49e6c7c486e227bee2e04b8879a675a42c1ad7cca4eb86b2cf url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-publish-consume-example.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Publish and Then Consume a Topic with Kafka Connector

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This example shows how to use two Apache Kafka Connector operations, **Publish** and **Consume**, to
publish a message to Apache Kafka and then retrieve it. The example contains two flows:

- The first flow is the Producer flow, which publishes a message to Apache Kafka.

- The second flow is the Consumer flow, which consumes a message from Apache Kafka.

![Apache Kafka Connector Producer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-producer-studio-flow.png)

![Apache Kafka Connector Consumer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-consumer-studio-flow.png)

## Configure the First Flow

Configure the first flow that publishes a message to Apache Kafka. Creating the first flow involves
configuring a **Listener** component, a **Logger** component, a **Publish** operation, and a **Set
Payload** transformer.

### Configure the HTTP Listener

Configure the **Listener** component to initiate a Mule flow when a call is made to the
`/pushMessage` path:

1.  Create a new Mule project in Studio.

2.  From the **Mule Palette** view, select **HTTP** and drag the **Listener** component to the
    canvas.

3.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

4.  Accept the defaults.

5.  In the properties window, set the **Path** field value to `/pushMessage`.

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>#["Message: '" payload.message "' is going to be published to topic: '" payload.topic "'."]</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-logger-config-publish.png)

### Add the Publish Operation

Add the **Publish** operation to publish a message to the specified Kafka topic:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Publish** operation to
    the right of **Logger**.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector operation.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr><tr><td><p>Topic</p></td><td><p><code>\#[payload.topic]</code></p></td></tr><tr><td><p>Key</p></td><td><p><code>#[now()]</code></p></td></tr><tr><td><p>Message</p></td><td><p><code>payload</code></p></td></tr></tbody></table>

    The following image shows an example of the **Publish** configuration in the properties window:

    ![Publish properties window configuration](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-publish.png)

### Add the Set Payload Transformer

Add the **Set Payload** transformer to push the response builder:

1.  From the **Mule Palette** view, select **Core** and drag the **Set Payload** transformer to the
    right of **Publish**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the transformer, such as <code>Push response builder</code>.</p></td></tr><tr><td><p>Value</p></td><td><p><code>Message successfully sent to Apache Kafka topic.</code></p></td></tr></tbody></table>

    The following image shows an example of the **Set Payload** configuration in the properties
    window:

    ![Set Payload properties window configuration](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-set-payload.png)

## Configure the Second Flow

Configure the second flow that consumes a message from Apache Kafka. Creating the second flow
involves configuring a **Message listener** source and a **Logger** component.

### Add the Message Listener Source

Add the **Message listener** source to consume a message endpoint:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Message listener** source
    to the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish.**

    3.  In the **Group ID** field, enter `${consumer.groupId}`.

    4.  In the **Topic Subscription Patterns** field, select **Edit inline** and then click the
        green plus sign.

    5.  Enter the value `${topic1}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector source.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr></tbody></table>

    The following image shows an example of the **Message listener** configuration in the properties
    window:

    ![Message listener properties window configuration](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-message-listener-config.png)

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Message listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>"New message arrived: " payload ", key:" attributes.key ", partition:" attributes.partition ", offset:" ++ attributes.offset</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-logger-config-consume.png)

## XML for This Example

Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule
app:

```xml
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:Kafka="http://www.mulesoft.org/schema/mule/Kafka"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:spring="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/http
  http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
  http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans-current.xsd
	http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
  <configuration-properties file="mule-app.properties">
	</configuration-properties>
  <http:listener-config name="HTTP_Listener_config"
    doc:name="HTTP Listener config"  >
  <http:listener-connection host="0.0.0.0" port="8081" />
  </http:listener-config>

  <kafka:consumer-config name="Apache_Kafka_Consumer_configuration"
 	  doc:name="Apache Kafka Consumer configuration" >
	  <kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  <kafka:topic-patterns >
	    <kafka:topic-pattern value='${topic1}
	    &lt;kafka:topic-pattern value="topic-1" /&gt;
	    &lt;kafka:topic-pattern value="topic-2" /&gt;
	    &lt;/kafka:topic-patterns&gt;]' />
	  </kafka:topic-patterns>
	  </kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<kafka:producer-config name="Apache_Kafka_Producer_configuration"
	  doc:name="Apache Kafka Producer configuration" >
	  <kafka:producer-plaintext-connection >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  </kafka:producer-plaintext-connection>
	  </kafka:producer-config>
	<kafka:consumer-config name="Apache_Kafka_Consumer_configuration1" doc:name="Apache Kafka Consumer configuration" >
		<kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
			<kafka:bootstrap-servers >
				<kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
			</kafka:bootstrap-servers>
			<kafka:topic-patterns >
				<kafka:topic-pattern value="${config.topics}" />
			</kafka:topic-patterns>
		</kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<flow name="Producer-Flow" >
		<http:listener doc:name="Push message endpoint" config-ref="HTTP_Listener_config" path="/pushMessage" />
		<logger level="INFO" doc:name="Logger" message="&amp;quot;Message: '&amp;quot; ++ payload.message ++ &amp;quot;' is going to be published to topic: '&amp;quot; ++ payload.topic ++ &amp;quot;'.&amp;quot;" />
		<kafka:publish doc:name="Producer" topic="#[payload.topic]" key="#[now()]" config-ref="Apache_Kafka_Producer_configuration" />
		<set-payload value="Message successfully sent to Apache Kafka topic." doc:name="Push response builder" />
	</flow>
	<flow name="Consumer-Flow" >
		<kafka:message-listener doc:name="Consume message endpoint" config-ref="Apache_Kafka_Consumer_configuration"/>
		<logger level="INFO" doc:name="Logger" message="'New message arrived: ' ++ payload ++ &amp;quot;, key:&amp;quot; ++ attributes.key ++ &amp;quot;, partition:&amp;quot; ++ attributes.partition ++ &amp;quot;, offset:&amp;quot; ++ attributes.offset"/>
	</flow>
</mule>
```

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=d10df8fc999e2c07f31b5b82331d85e78078195b8981d8d5542a55d6dc49a482 url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-publish-consume-example.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Publish and Then Consume a Topic with Kafka Connector

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This example shows how to use two Apache Kafka Connector operations, **Publish** and **Consume**, to
publish a message to Apache Kafka and then retrieve it. The example contains two flows:

- The first flow is the Producer flow, which publishes a message to Apache Kafka.

- The second flow is the Consumer flow, which consumes a message from Apache Kafka.

![Apache Kafka Connector Producer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-producer-studio-flow.png)

![Apache Kafka Connector Consumer flow in Studio](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-consumer-studio-flow.png)

## Configure the First Flow

Configure the first flow that publishes a message to Apache Kafka. Creating the first flow involves
configuring a **Listener** component, a **Logger** component, a **Publish** operation, and a **Set
Payload** transformer.

### Configure the HTTP Listener

Configure the **Listener** component to initiate a Mule flow when a call is made to the
`/pushMessage` path:

1.  Create a new Mule project in Studio.

2.  From the **Mule Palette** view, select **HTTP** and drag the **Listener** component to the
    canvas.

3.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

4.  Accept the defaults.

5.  In the properties window, set the **Path** field value to `/pushMessage`.

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>#["Message: '" payload.message "' is going to be published to topic: '" payload.topic "'."]</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-logger-config-publish.png)

### Add the Publish Operation

Add the **Publish** operation to publish a message to the specified Kafka topic:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Publish** operation to
    the right of **Logger**.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector operation.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr><tr><td><p>Topic</p></td><td><p><code>\#[payload.topic]</code></p></td></tr><tr><td><p>Key</p></td><td><p><code>#[now()]</code></p></td></tr><tr><td><p>Message</p></td><td><p><code>payload</code></p></td></tr></tbody></table>

    The following image shows an example of the **Publish** configuration in the properties window:

    ![Publish properties window configuration](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-publish.png)

### Add the Set Payload Transformer

Add the **Set Payload** transformer to push the response builder:

1.  From the **Mule Palette** view, select **Core** and drag the **Set Payload** transformer to the
    right of **Publish**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the transformer, such as <code>Push response builder</code>.</p></td></tr><tr><td><p>Value</p></td><td><p><code>Message successfully sent to Apache Kafka topic.</code></p></td></tr></tbody></table>

    The following image shows an example of the **Set Payload** configuration in the properties
    window:

    ![Set Payload properties window configuration](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-set-payload.png)

## Configure the Second Flow

Configure the second flow that consumes a message from Apache Kafka. Creating the second flow
involves configuring a **Message listener** source and a **Logger** component.

### Add the Message Listener Source

Add the **Message listener** source to consume a message endpoint:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Message listener** source
    to the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish.**

    3.  In the **Group ID** field, enter `${consumer.groupId}`.

    4.  In the **Topic Subscription Patterns** field, select **Edit inline** and then click the
        green plus sign.

    5.  Enter the value `${topic1}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector source.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr></tbody></table>

    The following image shows an example of the **Message listener** configuration in the properties
    window:

    ![Message listener properties window configuration](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-message-listener-config.png)

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Message listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>"New message arrived: " payload ", key:" attributes.key ", partition:" attributes.partition ", offset:" ++ attributes.offset</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-logger-config-consume.png)

## XML for This Example

Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule
app:

```xml
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:Kafka="http://www.mulesoft.org/schema/mule/Kafka"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:spring="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/http
  http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
  http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans-current.xsd
	http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
  <configuration-properties file="mule-app.properties">
	</configuration-properties>
  <http:listener-config name="HTTP_Listener_config"
    doc:name="HTTP Listener config"  >
  <http:listener-connection host="0.0.0.0" port="8081" />
  </http:listener-config>

  <kafka:consumer-config name="Apache_Kafka_Consumer_configuration"
 	  doc:name="Apache Kafka Consumer configuration" >
	  <kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  <kafka:topic-patterns >
	    <kafka:topic-pattern value='${topic1}
	    &lt;kafka:topic-pattern value="topic-1" /&gt;
	    &lt;kafka:topic-pattern value="topic-2" /&gt;
	    &lt;/kafka:topic-patterns&gt;]' />
	  </kafka:topic-patterns>
	  </kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<kafka:producer-config name="Apache_Kafka_Producer_configuration"
	  doc:name="Apache Kafka Producer configuration" >
	  <kafka:producer-plaintext-connection >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  </kafka:producer-plaintext-connection>
	  </kafka:producer-config>
	<kafka:consumer-config name="Apache_Kafka_Consumer_configuration1" doc:name="Apache Kafka Consumer configuration" >
		<kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
			<kafka:bootstrap-servers >
				<kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
			</kafka:bootstrap-servers>
			<kafka:topic-patterns >
				<kafka:topic-pattern value="${config.topics}" />
			</kafka:topic-patterns>
		</kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<flow name="Producer-Flow" >
		<http:listener doc:name="Push message endpoint" config-ref="HTTP_Listener_config" path="/pushMessage" />
		<logger level="INFO" doc:name="Logger" message="&amp;quot;Message: '&amp;quot; ++ payload.message ++ &amp;quot;' is going to be published to topic: '&amp;quot; ++ payload.topic ++ &amp;quot;'.&amp;quot;" />
		<kafka:publish doc:name="Producer" topic="#[payload.topic]" key="#[now()]" config-ref="Apache_Kafka_Producer_configuration" />
		<set-payload value="Message successfully sent to Apache Kafka topic." doc:name="Push response builder" />
	</flow>
	<flow name="Consumer-Flow" >
		<kafka:message-listener doc:name="Consume message endpoint" config-ref="Apache_Kafka_Consumer_configuration"/>
		<logger level="INFO" doc:name="Logger" message="'New message arrived: ' ++ payload ++ &amp;quot;, key:&amp;quot; ++ attributes.key ++ &amp;quot;, partition:&amp;quot; ++ attributes.partition ++ &amp;quot;, offset:&amp;quot; ++ attributes.offset"/>
	</flow>
</mule>
```

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=bdd034722977ea3634fcb336668714be76a25555831d7ba96fbed935ffff0c3f url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-publish-consume-example.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Publish and Then Consume a Topic with Kafka Connector

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

This example shows how to use two Apache Kafka Connector operations, **Publish** and **Consume**, to
publish a message to Apache Kafka and then retrieve it. The example contains two flows:

- The first flow is the Producer flow, which publishes a message to Apache Kafka.

- The second flow is the Consumer flow, which consumes a message from Apache Kafka.

![Apache Kafka Connector Producer flow in Studio](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-producer-studio-flow.png)

![Apache Kafka Connector Consumer flow in Studio](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-consumer-studio-flow.png)

## Configure the First Flow

Configure the first flow that publishes a message to Apache Kafka. Creating the first flow involves
configuring a **Listener** component, a **Logger** component, a **Publish** operation, and a **Set
Payload** transformer.

### Configure the HTTP Listener

Configure the **Listener** component to initiate a Mule flow when a call is made to the
`/pushMessage` path:

1.  Create a new Mule project in Studio.

2.  From the **Mule Palette** view, select **HTTP** and drag the **Listener** component to the
    canvas.

3.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

4.  Accept the defaults.

5.  In the properties window, set the **Path** field value to `/pushMessage`.

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>#["Message: '" payload.message "' is going to be published to topic: '" payload.topic "'."]</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-logger-config-publish.png)

### Add the Publish Operation

Add the **Publish** operation to publish a message to the specified Kafka topic:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Publish** operation to
    the right of **Logger**.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector operation.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr><tr><td><p>Topic</p></td><td><p><code>\#[payload.topic]</code></p></td></tr><tr><td><p>Key</p></td><td><p><code>#[now()]</code></p></td></tr><tr><td><p>Message</p></td><td><p><code>payload</code></p></td></tr></tbody></table>

    The following image shows an example of the **Publish** configuration in the properties window:

    ![Publish properties window configuration](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-publish.png)

### Add the Set Payload Transformer

Add the **Set Payload** transformer to push the response builder:

1.  From the **Mule Palette** view, select **Core** and drag the **Set Payload** transformer to the
    right of **Publish**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the transformer, such as <code>Push response builder</code>.</p></td></tr><tr><td><p>Value</p></td><td><p><code>Message successfully sent to Apache Kafka topic.</code></p></td></tr></tbody></table>

    The following image shows an example of the **Set Payload** configuration in the properties
    window:

    ![Set Payload properties window configuration](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-set-payload.png)

## Configure the Second Flow

Configure the second flow that consumes a message from Apache Kafka. Creating the second flow
involves configuring a **Message listener** source and a **Logger** component.

### Add the Message Listener Source

Add the **Message listener** source to consume a message endpoint:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Message listener** source
    to the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    global element.

3.  Configure the global element as follows:

    1.  In the **Bootstrap Server URLs** field, select **Edit inline** and then click the green plus
        sign.

    2.  Enter the value `${config.basic.bootstrapServers}` and click **Finish.**

    3.  In the **Group ID** field, enter `${consumer.groupId}`.

    4.  In the **Topic Subscription Patterns** field, select **Edit inline** and then click the
        green plus sign.

    5.  Enter the value `${topic1}` and click **Finish**.

4.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the connector source.</p></td></tr><tr><td><p>Connector configuration</p></td><td><p>Global configuration you just created.</p></td></tr></tbody></table>

    The following image shows an example of the **Message listener** configuration in the properties
    window:

    ![Message listener properties window configuration](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-message-listener-config.png)

### Add the Logger Component

Add the **Logger** component to display the response in the Mule console:

1.  From the **Mule Palette** view, select **Core** and drag a **Logger** component to the right of
    **Message listener**.

2.  In the properties window, configure the following fields:

    <table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Value</th></tr></thead><tbody><tr><td><p>Display Name</p></td><td><p>Name for the logger.</p></td></tr><tr><td><p>Message</p></td><td><p><code>"New message arrived: " payload ", key:" attributes.key ", partition:" attributes.partition ", offset:" ++ attributes.offset</code></p></td></tr><tr><td><p>Level</p></td><td><p>INFO (Default)</p></td></tr></tbody></table>

    The following image shows an example of the **Logger** configuration in the properties window:

    ![Logger properties window configuration](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-logger-config-consume.png)

## XML for This Example

Paste this code into the Studio XML editor to quickly load the flow for this example into your Mule
app:

```xml
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:Kafka="http://www.mulesoft.org/schema/mule/Kafka"
	xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:spring="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/http
  http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
  http://www.springframework.org/schema/beans
	http://www.springframework.org/schema/beans/spring-beans-current.xsd
	http://www.mulesoft.org/schema/mule/core
	http://www.mulesoft.org/schema/mule/core/current/mule.xsd
	http://www.mulesoft.org/schema/mule/http
	http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
	http://www.mulesoft.org/schema/mule/ee/core
	http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
	http://www.mulesoft.org/schema/mule/kafka
	http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">
  <configuration-properties file="mule-app.properties">
	</configuration-properties>
  <http:listener-config name="HTTP_Listener_config"
    doc:name="HTTP Listener config"  >
  <http:listener-connection host="0.0.0.0" port="8081" />
  </http:listener-config>

  <kafka:consumer-config name="Apache_Kafka_Consumer_configuration"
 	  doc:name="Apache Kafka Consumer configuration" >
	  <kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  <kafka:topic-patterns >
	    <kafka:topic-pattern value='${topic1}
	    &lt;kafka:topic-pattern value="topic-1" /&gt;
	    &lt;kafka:topic-pattern value="topic-2" /&gt;
	    &lt;/kafka:topic-patterns&gt;]' />
	  </kafka:topic-patterns>
	  </kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<kafka:producer-config name="Apache_Kafka_Producer_configuration"
	  doc:name="Apache Kafka Producer configuration" >
	  <kafka:producer-plaintext-connection >
	  <kafka:bootstrap-servers >
	    <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
	  </kafka:bootstrap-servers>
	  </kafka:producer-plaintext-connection>
	  </kafka:producer-config>
	<kafka:consumer-config name="Apache_Kafka_Consumer_configuration1" doc:name="Apache Kafka Consumer configuration" >
		<kafka:consumer-plaintext-connection groupId="${consumer.groupId}" >
			<kafka:bootstrap-servers >
				<kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
			</kafka:bootstrap-servers>
			<kafka:topic-patterns >
				<kafka:topic-pattern value="${config.topics}" />
			</kafka:topic-patterns>
		</kafka:consumer-plaintext-connection>
	</kafka:consumer-config>
	<flow name="Producer-Flow" >
		<http:listener doc:name="Push message endpoint" config-ref="HTTP_Listener_config" path="/pushMessage" />
		<logger level="INFO" doc:name="Logger" message="&amp;quot;Message: '&amp;quot; ++ payload.message ++ &amp;quot;' is going to be published to topic: '&amp;quot; ++ payload.topic ++ &amp;quot;'.&amp;quot;" />
		<kafka:publish doc:name="Producer" topic="#[payload.topic]" key="#[now()]" config-ref="Apache_Kafka_Producer_configuration" />
		<set-payload value="Message successfully sent to Apache Kafka topic." doc:name="Push response builder" />
	</flow>
	<flow name="Consumer-Flow" >
		<kafka:message-listener doc:name="Consume message endpoint" config-ref="Apache_Kafka_Consumer_configuration"/>
		<logger level="INFO" doc:name="Logger" message="'New message arrived: ' ++ payload ++ &amp;quot;, key:&amp;quot; ++ attributes.key ++ &amp;quot;, partition:&amp;quot; ++ attributes.partition ++ &amp;quot;, offset:&amp;quot; ++ attributes.offset"/>
	</flow>
</mule>
```

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=e8a9d67db52bfe598281ab3d57b268e72ad8a3b05c6010e2bcb6fe9f6b955ee3 url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-bulk-publish-example.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Publish Multiple Messages with Bulk Publish: Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to use the **Bulk Publish** operation (`<kafka:bulk-publish>`) of
Kafka Connector to publish several messages to Apache Kafka with a single operation call.

Imagine you receive a list of orders in your Mule app and want to publish each order as its own
Kafka message, without calling **Publish** once per order. **Bulk Publish** takes an array of
ready-made messages and sends all of them in one call.

## Understand the KafkaMessage Object

**Publish** lets you set **Topic**, **Partition**, and **Key** directly as fields on the operation,
because it only sends one message. **Bulk Publish** sends many messages at once, and each one can go
to a different topic or partition, so instead of operation fields, you build an array where every
entry carries its own routing information.

Each entry of that array is a `KafkaMessage`, made of two parts:

<table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong><code>attributes</code></strong></p></td><td><div><div><p>Where this message goes: <code>topic</code> (required), <code>partition</code> (required, a number: <code>0</code> if you don’t need to target a specific one), <code>key</code> (optional).</p></div></div></td></tr><tr><td><p><strong><code>payload</code></strong></p></td><td><div><div><p>The content of the message.</p></div></div></td></tr></tbody></table>

## Build the Array of KafkaMessage Objects with DataWeave

`KafkaMessage` is a Java object, so a plain DataWeave object like `{topic: "orders"}` doesn’t work
on its own. Tell DataWeave which Java class to build by writing the object as usual and tagging it
with `as Object {class: "…​"}`.

For example, if the incoming payload is an array of orders like this:

```json
[
  { "orderId": "1001", "description": "2 units of SKU-42" },
  { "orderId": "1002", "description": "1 unit of SKU-77" }
]
```

The following DataWeave script turns that array into an array of `KafkaMessage` objects ready to
publish:

```dataweave
%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}
```

> [!NOTE] Unlike **Publish**, **Bulk Publish** has no "let Kafka choose the partition" option.
> `partition` always takes a real partition number, and `0` means partition 0, not "unspecified." To
> spread messages across a target topic that has more than one partition, calculate the partition
> per message yourself (for example, hashing the key against the topic’s partition count) instead of
> sending every message to `0`.

Set the **Messages** field of **Bulk Publish** to this expression (or reference the variable that
holds its result, if you built it in an earlier **Transform Message** step).

## Configure the Bulk Publish Operation

To configure the **Bulk Publish** operation in Anypoint Studio:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Bulk Publish** operation
    onto the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    **Producer** global element, or select an existing one.

3.  Set the **Messages** field to the DataWeave expression that builds the array of `KafkaMessage`
    objects, for example `#[payload]`.

**Bulk Publish** returns an array with one `KafkaMessageMetadata` entry per message that was
published successfully, with `topic`, `partition`, and `offset` for each one. Because every message
is sent independently, this array isn’t guaranteed to come back in the same order as the input
array. Use the `topic`/`partition`/`offset` in each entry, not its position, to identify a message.

## XML for This Example

Paste this code into the Studio XML editor to load the flow for this example into your Mule app. A
**Scheduler** triggers the flow periodically. In a real app, replace the fixed list of orders in
**Set orders payload** with wherever your orders actually come from (a database query, an HTTP call,
and so on):

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
    xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
    xmlns="http://www.mulesoft.org/schema/mule/core"
    xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
http://www.mulesoft.org/schema/mule/kafka http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">

    <kafka:producer-config name="Apache_Kafka_Producer_configuration" doc:name="Apache Kafka Producer configuration">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
            </kafka:bootstrap-servers>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>

    <flow name="Bulk-Publish-Producer-Flow">
        <scheduler doc:name="Scheduler">
            <scheduling-strategy>
                <fixed-frequency frequency="3" timeUnit="MINUTES" />
            </scheduling-strategy>
        </scheduler>
        <set-payload doc:name="Set orders payload"
            value='#[[{"orderId": "1001", "description": "2 units of SKU-42"},{"orderId": "1002", "description": "1 unit of SKU-77"}]]'/>
        <ee:transform doc:name="Build KafkaMessage array">
            <ee:message>
                <ee:set-payload><![CDATA[%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}]]></ee:set-payload>
            </ee:message>
        </ee:transform>
        <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
            <kafka:messages>#[payload]</kafka:messages>
        </kafka:bulk-publish>
        <logger level="INFO" doc:name="Log published metadata"
            message="#[payload map (m) -> 'topic: ' ++ m.topic ++ ', partition: ' ++ m.partition ++ ', offset: ' ++ m.offset]" />
    </flow>
</mule>
```

## Handle Publishing Errors

Because **Bulk Publish** sends every message independently, some messages in the array can succeed
while others fail in the same call. For example, one message might point to a topic that doesn’t
exist. Wrap the operation in a `try` to catch failures without losing the messages that went
through:

```xml
<try doc:name="Try">
    <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
        <kafka:messages>#[payload]</kafka:messages>
    </kafka:bulk-publish>
    <error-handler>
        <on-error-continue type="KAFKA:INVALID_TOPIC_PARTITION" doc:name="Invalid topic or partition">
            <logger level="ERROR" message="#['One of the messages targeted an invalid topic or partition: ' ++ error.description]" />
        </on-error-continue>
    </error-handler>
</try>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-examples)

- [Bulk Publish Reference](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-reference#bulkPublish)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=2aa10639f4b03df2bbcdfc250bda0ef6dd6f45ba1bd1e5a88093dd101c9357c8 url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-bulk-publish-example.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Publish Multiple Messages with Bulk Publish: Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to use the **Bulk Publish** operation (`<kafka:bulk-publish>`) of
Kafka Connector to publish several messages to Apache Kafka with a single operation call.

Imagine you receive a list of orders in your Mule app and want to publish each order as its own
Kafka message, without calling **Publish** once per order. **Bulk Publish** takes an array of
ready-made messages and sends all of them in one call.

## Understand the KafkaMessage Object

**Publish** lets you set **Topic**, **Partition**, and **Key** directly as fields on the operation,
because it only sends one message. **Bulk Publish** sends many messages at once, and each one can go
to a different topic or partition, so instead of operation fields, you build an array where every
entry carries its own routing information.

Each entry of that array is a `KafkaMessage`, made of two parts:

<table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong><code>attributes</code></strong></p></td><td><div><div><p>Where this message goes: <code>topic</code> (required), <code>partition</code> (required, a number: <code>0</code> if you don’t need to target a specific one), <code>key</code> (optional).</p></div></div></td></tr><tr><td><p><strong><code>payload</code></strong></p></td><td><div><div><p>The content of the message.</p></div></div></td></tr></tbody></table>

## Build the Array of KafkaMessage Objects with DataWeave

`KafkaMessage` is a Java object, so a plain DataWeave object like `{topic: "orders"}` doesn’t work
on its own. Tell DataWeave which Java class to build by writing the object as usual and tagging it
with `as Object {class: "…​"}`.

For example, if the incoming payload is an array of orders like this:

```json
[
  { "orderId": "1001", "description": "2 units of SKU-42" },
  { "orderId": "1002", "description": "1 unit of SKU-77" }
]
```

The following DataWeave script turns that array into an array of `KafkaMessage` objects ready to
publish:

```dataweave
%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}
```

> [!NOTE] Unlike **Publish**, **Bulk Publish** has no "let Kafka choose the partition" option.
> `partition` always takes a real partition number, and `0` means partition 0, not "unspecified." To
> spread messages across a target topic that has more than one partition, calculate the partition
> per message yourself (for example, hashing the key against the topic’s partition count) instead of
> sending every message to `0`.

Set the **Messages** field of **Bulk Publish** to this expression (or reference the variable that
holds its result, if you built it in an earlier **Transform Message** step).

## Configure the Bulk Publish Operation

To configure the **Bulk Publish** operation in Anypoint Studio:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Bulk Publish** operation
    onto the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    **Producer** global element, or select an existing one.

3.  Set the **Messages** field to the DataWeave expression that builds the array of `KafkaMessage`
    objects, for example `#[payload]`.

**Bulk Publish** returns an array with one `KafkaMessageMetadata` entry per message that was
published successfully, with `topic`, `partition`, and `offset` for each one. Because every message
is sent independently, this array isn’t guaranteed to come back in the same order as the input
array. Use the `topic`/`partition`/`offset` in each entry, not its position, to identify a message.

## XML for This Example

Paste this code into the Studio XML editor to load the flow for this example into your Mule app. A
**Scheduler** triggers the flow periodically. In a real app, replace the fixed list of orders in
**Set orders payload** with wherever your orders actually come from (a database query, an HTTP call,
and so on):

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
    xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
    xmlns="http://www.mulesoft.org/schema/mule/core"
    xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
http://www.mulesoft.org/schema/mule/kafka http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">

    <kafka:producer-config name="Apache_Kafka_Producer_configuration" doc:name="Apache Kafka Producer configuration">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
            </kafka:bootstrap-servers>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>

    <flow name="Bulk-Publish-Producer-Flow">
        <scheduler doc:name="Scheduler">
            <scheduling-strategy>
                <fixed-frequency frequency="3" timeUnit="MINUTES" />
            </scheduling-strategy>
        </scheduler>
        <set-payload doc:name="Set orders payload"
            value='#[[{"orderId": "1001", "description": "2 units of SKU-42"},{"orderId": "1002", "description": "1 unit of SKU-77"}]]'/>
        <ee:transform doc:name="Build KafkaMessage array">
            <ee:message>
                <ee:set-payload><![CDATA[%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}]]></ee:set-payload>
            </ee:message>
        </ee:transform>
        <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
            <kafka:messages>#[payload]</kafka:messages>
        </kafka:bulk-publish>
        <logger level="INFO" doc:name="Log published metadata"
            message="#[payload map (m) -> 'topic: ' ++ m.topic ++ ', partition: ' ++ m.partition ++ ', offset: ' ++ m.offset]" />
    </flow>
</mule>
```

## Handle Publishing Errors

Because **Bulk Publish** sends every message independently, some messages in the array can succeed
while others fail in the same call. For example, one message might point to a topic that doesn’t
exist. Wrap the operation in a `try` to catch failures without losing the messages that went
through:

```xml
<try doc:name="Try">
    <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
        <kafka:messages>#[payload]</kafka:messages>
    </kafka:bulk-publish>
    <error-handler>
        <on-error-continue type="KAFKA:INVALID_TOPIC_PARTITION" doc:name="Invalid topic or partition">
            <logger level="ERROR" message="#['One of the messages targeted an invalid topic or partition: ' ++ error.description]" />
        </on-error-continue>
    </error-handler>
</try>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-examples)

- [Bulk Publish Reference](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-reference#bulkPublish)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=64ea42b32c4fdb9d7412ac378164d830f47b39dd9e357773860d500c572c31ee url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-bulk-publish-example.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Publish Multiple Messages with Bulk Publish: Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to use the **Bulk Publish** operation (`<kafka:bulk-publish>`) of
Kafka Connector to publish several messages to Apache Kafka with a single operation call.

Imagine you receive a list of orders in your Mule app and want to publish each order as its own
Kafka message, without calling **Publish** once per order. **Bulk Publish** takes an array of
ready-made messages and sends all of them in one call.

## Understand the KafkaMessage Object

**Publish** lets you set **Topic**, **Partition**, and **Key** directly as fields on the operation,
because it only sends one message. **Bulk Publish** sends many messages at once, and each one can go
to a different topic or partition, so instead of operation fields, you build an array where every
entry carries its own routing information.

Each entry of that array is a `KafkaMessage`, made of two parts:

<table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong><code>attributes</code></strong></p></td><td><div><div><p>Where this message goes: <code>topic</code> (required), <code>partition</code> (required, a number: <code>0</code> if you don’t need to target a specific one), <code>key</code> (optional).</p></div></div></td></tr><tr><td><p><strong><code>payload</code></strong></p></td><td><div><div><p>The content of the message.</p></div></div></td></tr></tbody></table>

## Build the Array of KafkaMessage Objects with DataWeave

`KafkaMessage` is a Java object, so a plain DataWeave object like `{topic: "orders"}` doesn’t work
on its own. Tell DataWeave which Java class to build by writing the object as usual and tagging it
with `as Object {class: "…​"}`.

For example, if the incoming payload is an array of orders like this:

```json
[
  { "orderId": "1001", "description": "2 units of SKU-42" },
  { "orderId": "1002", "description": "1 unit of SKU-77" }
]
```

The following DataWeave script turns that array into an array of `KafkaMessage` objects ready to
publish:

```dataweave
%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}
```

> [!NOTE] Unlike **Publish**, **Bulk Publish** has no "let Kafka choose the partition" option.
> `partition` always takes a real partition number, and `0` means partition 0, not "unspecified." To
> spread messages across a target topic that has more than one partition, calculate the partition
> per message yourself (for example, hashing the key against the topic’s partition count) instead of
> sending every message to `0`.

Set the **Messages** field of **Bulk Publish** to this expression (or reference the variable that
holds its result, if you built it in an earlier **Transform Message** step).

## Configure the Bulk Publish Operation

To configure the **Bulk Publish** operation in Anypoint Studio:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Bulk Publish** operation
    onto the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    **Producer** global element, or select an existing one.

3.  Set the **Messages** field to the DataWeave expression that builds the array of `KafkaMessage`
    objects, for example `#[payload]`.

**Bulk Publish** returns an array with one `KafkaMessageMetadata` entry per message that was
published successfully, with `topic`, `partition`, and `offset` for each one. Because every message
is sent independently, this array isn’t guaranteed to come back in the same order as the input
array. Use the `topic`/`partition`/`offset` in each entry, not its position, to identify a message.

## XML for This Example

Paste this code into the Studio XML editor to load the flow for this example into your Mule app. A
**Scheduler** triggers the flow periodically. In a real app, replace the fixed list of orders in
**Set orders payload** with wherever your orders actually come from (a database query, an HTTP call,
and so on):

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
    xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
    xmlns="http://www.mulesoft.org/schema/mule/core"
    xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
http://www.mulesoft.org/schema/mule/kafka http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">

    <kafka:producer-config name="Apache_Kafka_Producer_configuration" doc:name="Apache Kafka Producer configuration">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
            </kafka:bootstrap-servers>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>

    <flow name="Bulk-Publish-Producer-Flow">
        <scheduler doc:name="Scheduler">
            <scheduling-strategy>
                <fixed-frequency frequency="3" timeUnit="MINUTES" />
            </scheduling-strategy>
        </scheduler>
        <set-payload doc:name="Set orders payload"
            value='#[[{"orderId": "1001", "description": "2 units of SKU-42"},{"orderId": "1002", "description": "1 unit of SKU-77"}]]'/>
        <ee:transform doc:name="Build KafkaMessage array">
            <ee:message>
                <ee:set-payload><![CDATA[%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}]]></ee:set-payload>
            </ee:message>
        </ee:transform>
        <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
            <kafka:messages>#[payload]</kafka:messages>
        </kafka:bulk-publish>
        <logger level="INFO" doc:name="Log published metadata"
            message="#[payload map (m) -> 'topic: ' ++ m.topic ++ ', partition: ' ++ m.partition ++ ', offset: ' ++ m.offset]" />
    </flow>
</mule>
```

## Handle Publishing Errors

Because **Bulk Publish** sends every message independently, some messages in the array can succeed
while others fail in the same call. For example, one message might point to a topic that doesn’t
exist. Wrap the operation in a `try` to catch failures without losing the messages that went
through:

```xml
<try doc:name="Try">
    <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
        <kafka:messages>#[payload]</kafka:messages>
    </kafka:bulk-publish>
    <error-handler>
        <on-error-continue type="KAFKA:INVALID_TOPIC_PARTITION" doc:name="Invalid topic or partition">
            <logger level="ERROR" message="#['One of the messages targeted an invalid topic or partition: ' ++ error.description]" />
        </on-error-continue>
    </error-handler>
</try>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-examples)

- [Bulk Publish Reference](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-reference#bulkPublish)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=869f72899cdcb7d851fe3784a5f9a20fd3a34f4918626c62c55b53aefe9c4321 url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-bulk-publish-example.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Publish Multiple Messages with Bulk Publish: Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to use the **Bulk Publish** operation (`<kafka:bulk-publish>`) of
Kafka Connector to publish several messages to Apache Kafka with a single operation call.

Imagine you receive a list of orders in your Mule app and want to publish each order as its own
Kafka message, without calling **Publish** once per order. **Bulk Publish** takes an array of
ready-made messages and sends all of them in one call.

## Understand the KafkaMessage Object

**Publish** lets you set **Topic**, **Partition**, and **Key** directly as fields on the operation,
because it only sends one message. **Bulk Publish** sends many messages at once, and each one can go
to a different topic or partition, so instead of operation fields, you build an array where every
entry carries its own routing information.

Each entry of that array is a `KafkaMessage`, made of two parts:

<table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong><code>attributes</code></strong></p></td><td><div><div><p>Where this message goes: <code>topic</code> (required), <code>partition</code> (required, a number: <code>0</code> if you don’t need to target a specific one), <code>key</code> (optional).</p></div></div></td></tr><tr><td><p><strong><code>payload</code></strong></p></td><td><div><div><p>The content of the message.</p></div></div></td></tr></tbody></table>

## Build the Array of KafkaMessage Objects with DataWeave

`KafkaMessage` is a Java object, so a plain DataWeave object like `{topic: "orders"}` doesn’t work
on its own. Tell DataWeave which Java class to build by writing the object as usual and tagging it
with `as Object {class: "…​"}`.

For example, if the incoming payload is an array of orders like this:

```json
[
  { "orderId": "1001", "description": "2 units of SKU-42" },
  { "orderId": "1002", "description": "1 unit of SKU-77" }
]
```

The following DataWeave script turns that array into an array of `KafkaMessage` objects ready to
publish:

```dataweave
%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}
```

> [!NOTE] Unlike **Publish**, **Bulk Publish** has no "let Kafka choose the partition" option.
> `partition` always takes a real partition number, and `0` means partition 0, not "unspecified." To
> spread messages across a target topic that has more than one partition, calculate the partition
> per message yourself (for example, hashing the key against the topic’s partition count) instead of
> sending every message to `0`.

Set the **Messages** field of **Bulk Publish** to this expression (or reference the variable that
holds its result, if you built it in an earlier **Transform Message** step).

## Configure the Bulk Publish Operation

To configure the **Bulk Publish** operation in Anypoint Studio:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Bulk Publish** operation
    onto the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    **Producer** global element, or select an existing one.

3.  Set the **Messages** field to the DataWeave expression that builds the array of `KafkaMessage`
    objects, for example `#[payload]`.

**Bulk Publish** returns an array with one `KafkaMessageMetadata` entry per message that was
published successfully, with `topic`, `partition`, and `offset` for each one. Because every message
is sent independently, this array isn’t guaranteed to come back in the same order as the input
array. Use the `topic`/`partition`/`offset` in each entry, not its position, to identify a message.

## XML for This Example

Paste this code into the Studio XML editor to load the flow for this example into your Mule app. A
**Scheduler** triggers the flow periodically. In a real app, replace the fixed list of orders in
**Set orders payload** with wherever your orders actually come from (a database query, an HTTP call,
and so on):

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
    xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
    xmlns="http://www.mulesoft.org/schema/mule/core"
    xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
http://www.mulesoft.org/schema/mule/kafka http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">

    <kafka:producer-config name="Apache_Kafka_Producer_configuration" doc:name="Apache Kafka Producer configuration">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
            </kafka:bootstrap-servers>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>

    <flow name="Bulk-Publish-Producer-Flow">
        <scheduler doc:name="Scheduler">
            <scheduling-strategy>
                <fixed-frequency frequency="3" timeUnit="MINUTES" />
            </scheduling-strategy>
        </scheduler>
        <set-payload doc:name="Set orders payload"
            value='#[[{"orderId": "1001", "description": "2 units of SKU-42"},{"orderId": "1002", "description": "1 unit of SKU-77"}]]'/>
        <ee:transform doc:name="Build KafkaMessage array">
            <ee:message>
                <ee:set-payload><![CDATA[%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}]]></ee:set-payload>
            </ee:message>
        </ee:transform>
        <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
            <kafka:messages>#[payload]</kafka:messages>
        </kafka:bulk-publish>
        <logger level="INFO" doc:name="Log published metadata"
            message="#[payload map (m) -> 'topic: ' ++ m.topic ++ ', partition: ' ++ m.partition ++ ', offset: ' ++ m.offset]" />
    </flow>
</mule>
```

## Handle Publishing Errors

Because **Bulk Publish** sends every message independently, some messages in the array can succeed
while others fail in the same call. For example, one message might point to a topic that doesn’t
exist. Wrap the operation in a `try` to catch failures without losing the messages that went
through:

```xml
<try doc:name="Try">
    <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
        <kafka:messages>#[payload]</kafka:messages>
    </kafka:bulk-publish>
    <error-handler>
        <on-error-continue type="KAFKA:INVALID_TOPIC_PARTITION" doc:name="Invalid topic or partition">
            <logger level="ERROR" message="#['One of the messages targeted an invalid topic or partition: ' ++ error.description]" />
        </on-error-continue>
    </error-handler>
</try>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-examples)

- [Bulk Publish Reference](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-reference#bulkPublish)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=a7391f2b23b383298442ca7adb8d485ceea15a6de57d6e593ce01317436126f8 url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-bulk-publish-example.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Publish Multiple Messages with Bulk Publish: Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to use the **Bulk Publish** operation (`<kafka:bulk-publish>`) of
Kafka Connector to publish several messages to Apache Kafka with a single operation call.

Imagine you receive a list of orders in your Mule app and want to publish each order as its own
Kafka message, without calling **Publish** once per order. **Bulk Publish** takes an array of
ready-made messages and sends all of them in one call.

## Understand the KafkaMessage Object

**Publish** lets you set **Topic**, **Partition**, and **Key** directly as fields on the operation,
because it only sends one message. **Bulk Publish** sends many messages at once, and each one can go
to a different topic or partition, so instead of operation fields, you build an array where every
entry carries its own routing information.

Each entry of that array is a `KafkaMessage`, made of two parts:

<table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong><code>attributes</code></strong></p></td><td><div><div><p>Where this message goes: <code>topic</code> (required), <code>partition</code> (required, a number: <code>0</code> if you don’t need to target a specific one), <code>key</code> (optional).</p></div></div></td></tr><tr><td><p><strong><code>payload</code></strong></p></td><td><div><div><p>The content of the message.</p></div></div></td></tr></tbody></table>

## Build the Array of KafkaMessage Objects with DataWeave

`KafkaMessage` is a Java object, so a plain DataWeave object like `{topic: "orders"}` doesn’t work
on its own. Tell DataWeave which Java class to build by writing the object as usual and tagging it
with `as Object {class: "…​"}`.

For example, if the incoming payload is an array of orders like this:

```json
[
  { "orderId": "1001", "description": "2 units of SKU-42" },
  { "orderId": "1002", "description": "1 unit of SKU-77" }
]
```

The following DataWeave script turns that array into an array of `KafkaMessage` objects ready to
publish:

```dataweave
%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}
```

> [!NOTE] Unlike **Publish**, **Bulk Publish** has no "let Kafka choose the partition" option.
> `partition` always takes a real partition number, and `0` means partition 0, not "unspecified." To
> spread messages across a target topic that has more than one partition, calculate the partition
> per message yourself (for example, hashing the key against the topic’s partition count) instead of
> sending every message to `0`.

Set the **Messages** field of **Bulk Publish** to this expression (or reference the variable that
holds its result, if you built it in an earlier **Transform Message** step).

## Configure the Bulk Publish Operation

To configure the **Bulk Publish** operation in Anypoint Studio:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Bulk Publish** operation
    onto the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    **Producer** global element, or select an existing one.

3.  Set the **Messages** field to the DataWeave expression that builds the array of `KafkaMessage`
    objects, for example `#[payload]`.

**Bulk Publish** returns an array with one `KafkaMessageMetadata` entry per message that was
published successfully, with `topic`, `partition`, and `offset` for each one. Because every message
is sent independently, this array isn’t guaranteed to come back in the same order as the input
array. Use the `topic`/`partition`/`offset` in each entry, not its position, to identify a message.

## XML for This Example

Paste this code into the Studio XML editor to load the flow for this example into your Mule app. A
**Scheduler** triggers the flow periodically. In a real app, replace the fixed list of orders in
**Set orders payload** with wherever your orders actually come from (a database query, an HTTP call,
and so on):

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
    xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
    xmlns="http://www.mulesoft.org/schema/mule/core"
    xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
http://www.mulesoft.org/schema/mule/kafka http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">

    <kafka:producer-config name="Apache_Kafka_Producer_configuration" doc:name="Apache Kafka Producer configuration">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
            </kafka:bootstrap-servers>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>

    <flow name="Bulk-Publish-Producer-Flow">
        <scheduler doc:name="Scheduler">
            <scheduling-strategy>
                <fixed-frequency frequency="3" timeUnit="MINUTES" />
            </scheduling-strategy>
        </scheduler>
        <set-payload doc:name="Set orders payload"
            value='#[[{"orderId": "1001", "description": "2 units of SKU-42"},{"orderId": "1002", "description": "1 unit of SKU-77"}]]'/>
        <ee:transform doc:name="Build KafkaMessage array">
            <ee:message>
                <ee:set-payload><![CDATA[%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}]]></ee:set-payload>
            </ee:message>
        </ee:transform>
        <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
            <kafka:messages>#[payload]</kafka:messages>
        </kafka:bulk-publish>
        <logger level="INFO" doc:name="Log published metadata"
            message="#[payload map (m) -> 'topic: ' ++ m.topic ++ ', partition: ' ++ m.partition ++ ', offset: ' ++ m.offset]" />
    </flow>
</mule>
```

## Handle Publishing Errors

Because **Bulk Publish** sends every message independently, some messages in the array can succeed
while others fail in the same call. For example, one message might point to a topic that doesn’t
exist. Wrap the operation in a `try` to catch failures without losing the messages that went
through:

```xml
<try doc:name="Try">
    <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
        <kafka:messages>#[payload]</kafka:messages>
    </kafka:bulk-publish>
    <error-handler>
        <on-error-continue type="KAFKA:INVALID_TOPIC_PARTITION" doc:name="Invalid topic or partition">
            <logger level="ERROR" message="#['One of the messages targeted an invalid topic or partition: ' ++ error.description]" />
        </on-error-continue>
    </error-handler>
</try>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-examples)

- [Bulk Publish Reference](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-reference#bulkPublish)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=3ba4886717ca5f86eb1aebe98019613ba731d73090c5ee19e06d5c983d114038 url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-bulk-publish-example.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Publish Multiple Messages with Bulk Publish: Example

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The following example shows how to use the **Bulk Publish** operation (`<kafka:bulk-publish>`) of
Kafka Connector to publish several messages to Apache Kafka with a single operation call.

Imagine you receive a list of orders in your Mule app and want to publish each order as its own
Kafka message, without calling **Publish** once per order. **Bulk Publish** takes an array of
ready-made messages and sends all of them in one call.

## Understand the KafkaMessage Object

**Publish** lets you set **Topic**, **Partition**, and **Key** directly as fields on the operation,
because it only sends one message. **Bulk Publish** sends many messages at once, and each one can go
to a different topic or partition, so instead of operation fields, you build an array where every
entry carries its own routing information.

Each entry of that array is a `KafkaMessage`, made of two parts:

<table><colgroup><col> <col></colgroup><thead><tr><th>Field</th><th>Description</th></tr></thead><tbody><tr><td><p><strong><code>attributes</code></strong></p></td><td><div><div><p>Where this message goes: <code>topic</code> (required), <code>partition</code> (required, a number: <code>0</code> if you don’t need to target a specific one), <code>key</code> (optional).</p></div></div></td></tr><tr><td><p><strong><code>payload</code></strong></p></td><td><div><div><p>The content of the message.</p></div></div></td></tr></tbody></table>

## Build the Array of KafkaMessage Objects with DataWeave

`KafkaMessage` is a Java object, so a plain DataWeave object like `{topic: "orders"}` doesn’t work
on its own. Tell DataWeave which Java class to build by writing the object as usual and tagging it
with `as Object {class: "…​"}`.

For example, if the incoming payload is an array of orders like this:

```json
[
  { "orderId": "1001", "description": "2 units of SKU-42" },
  { "orderId": "1002", "description": "1 unit of SKU-77" }
]
```

The following DataWeave script turns that array into an array of `KafkaMessage` objects ready to
publish:

```dataweave
%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}
```

> [!NOTE] Unlike **Publish**, **Bulk Publish** has no "let Kafka choose the partition" option.
> `partition` always takes a real partition number, and `0` means partition 0, not "unspecified." To
> spread messages across a target topic that has more than one partition, calculate the partition
> per message yourself (for example, hashing the key against the topic’s partition count) instead of
> sending every message to `0`.

Set the **Messages** field of **Bulk Publish** to this expression (or reference the variable that
holds its result, if you built it in an earlier **Transform Message** step).

## Configure the Bulk Publish Operation

To configure the **Bulk Publish** operation in Anypoint Studio:

1.  From the **Mule Palette** view, select **Apache Kafka** and drag the **Bulk Publish** operation
    onto the canvas.

2.  In the properties window, click **+** next to the **Connector configuration** field to add a
    **Producer** global element, or select an existing one.

3.  Set the **Messages** field to the DataWeave expression that builds the array of `KafkaMessage`
    objects, for example `#[payload]`.

**Bulk Publish** returns an array with one `KafkaMessageMetadata` entry per message that was
published successfully, with `topic`, `partition`, and `offset` for each one. Because every message
is sent independently, this array isn’t guaranteed to come back in the same order as the input
array. Use the `topic`/`partition`/`offset` in each entry, not its position, to identify a message.

## XML for This Example

Paste this code into the Studio XML editor to load the flow for this example into your Mule app. A
**Scheduler** triggers the flow periodically. In a real app, replace the fixed list of orders in
**Set orders payload** with wherever your orders actually come from (a database query, an HTTP call,
and so on):

```xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
    xmlns:kafka="http://www.mulesoft.org/schema/mule/kafka"
    xmlns="http://www.mulesoft.org/schema/mule/core"
    xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd
http://www.mulesoft.org/schema/mule/kafka http://www.mulesoft.org/schema/mule/kafka/current/mule-kafka.xsd">

    <kafka:producer-config name="Apache_Kafka_Producer_configuration" doc:name="Apache Kafka Producer configuration">
        <kafka:producer-plaintext-connection>
            <kafka:bootstrap-servers>
                <kafka:bootstrap-server value="${config.basic.bootstrapServers}" />
            </kafka:bootstrap-servers>
        </kafka:producer-plaintext-connection>
    </kafka:producer-config>

    <flow name="Bulk-Publish-Producer-Flow">
        <scheduler doc:name="Scheduler">
            <scheduling-strategy>
                <fixed-frequency frequency="3" timeUnit="MINUTES" />
            </scheduling-strategy>
        </scheduler>
        <set-payload doc:name="Set orders payload"
            value='#[[{"orderId": "1001", "description": "2 units of SKU-42"},{"orderId": "1002", "description": "1 unit of SKU-77"}]]'/>
        <ee:transform doc:name="Build KafkaMessage array">
            <ee:message>
                <ee:set-payload><![CDATA[%dw 2.0
output application/java
---
payload map (order) -> {
    attributes: {
        topic: "orders",
        partition: 0,
        key: order.orderId
    },
    payload: order.description
} as Object {
    class: "com.mulesoft.connectors.kafka.api.operation.KafkaMessage"
}]]></ee:set-payload>
            </ee:message>
        </ee:transform>
        <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
            <kafka:messages>#[payload]</kafka:messages>
        </kafka:bulk-publish>
        <logger level="INFO" doc:name="Log published metadata"
            message="#[payload map (m) -> 'topic: ' ++ m.topic ++ ', partition: ' ++ m.partition ++ ', offset: ' ++ m.offset]" />
    </flow>
</mule>
```

## Handle Publishing Errors

Because **Bulk Publish** sends every message independently, some messages in the array can succeed
while others fail in the same call. For example, one message might point to a topic that doesn’t
exist. Wrap the operation in a `try` to catch failures without losing the messages that went
through:

```xml
<try doc:name="Try">
    <kafka:bulk-publish doc:name="Bulk publish orders" config-ref="Apache_Kafka_Producer_configuration">
        <kafka:messages>#[payload]</kafka:messages>
    </kafka:bulk-publish>
    <error-handler>
        <on-error-continue type="KAFKA:INVALID_TOPIC_PARTITION" doc:name="Invalid topic or partition">
            <logger level="ERROR" message="#['One of the messages targeted an invalid topic or partition: ' ++ error.description]" />
        </on-error-continue>
    </error-handler>
</try>
```

## See Also

- [Kafka Connector Examples](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-examples)

- [Bulk Publish Reference](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-reference#bulkPublish)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=47e12233515251ad6ea2f2d379672a3bd8428ee22779f3566929d41240084617 url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-troubleshooting.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Troubleshooting Apache Kafka Connector 4.10

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To troubleshoot Anypoint Connector for Apache Kafka (Apache Kafka Connector), become familiar with
the information about interpreting commonly thrown exception messages.

## Enable SSL Logging

Enable SSL logs to investigate an issue related to TLS communications.

Set your SSL log level depending on your required level of detail:

1.  Enable only SSL log details:

    `javax.net.debug=ssl`

2.  Enable only handshaking details. (The handshake protocol is a series of messages exchanged over
    the record protocol.)

    `javax.net.debug=ssl:handshake`

3.  Enable handshaking details and SSL details at the same time:

    `javax.net.debug=ssl, handshake`

4.  Enable the dumping of all details and traffic data:

    `javax.net.debug=all`

    > [!NOTE] This option is very verbose and under normal circumstances is not necessary.

> [!WARNING] SSL logging results in a performance impact for HTTPS or other TLS connections. Enable
> SSL logging only to troubleshoot a specific issue and do not enable it for extended periods. SSL
> logging produces a significant amount of log messages and can inundate your log file if it is left
> enabled and unattended.

To enable SSL logs:

Set the debug parameter as an argument in the runtime configuration for the application.

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and add `-M-Djavax.net.debug=ssl` in the **VM arguments** section.

## Enable Verbose Exception Logging

Enable verbose exception logs to show a complete stack trace of the error instead of the default
truncated output:

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and append the arguments in the **VM arguments** section to add the
    `mule.verbose.exceptions` property. For example:

    `-XX:PermSize=128M -XX:MaxPermSize=256M -Dmule.verbose.exceptions=true`

## Enable Verbose Logging

To get a better understanding of why an application’s interaction with Kafka Connector is failing,
temporarily enable verbose logging for the connector.

Remember to always disable enhanced verbosity after troubleshooting, because it can affect your Mule
application’s performance.

To enable verbose logging in the configuration file:

1.  Access Anypoint Studio and navigate to the **Package Explorer** view.

2.  Open your application’s project name.

3.  Open the `src/main/resources` folder.

4.  Open the `log4j2.xml` file inside the folder.

5.  Add an `<AsyncLogger>` tag inside the `<Loggers>` tag:

    ```xml
    			<Loggers>
    				...
    				<AsyncLogger name="com.mulesoft.connectors.kafka" level="DEBUG"/>
    				...
    			</Loggers>
    ```

6.  Save your application changes.

7.  Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule
    Application**.

## Troubleshoot Common Errors

Here is a list of the common Apache Kafka Connector errors and how to resolve them:

- [Failed to Load SSL Keystore](#failed-to-load-ssl-keystore)

### Failed to Load SSL Keystore

When the Kafka Connector configurations fail to load the required truststore files from the
classpath, you receive the following error:

```text
org.mule.runtime.api.connection.ConnectionException: Failed to load SSL keystore
```

The Kafka Connector configurations bundled with a dependency fail to establish connections even when
the required truststore files are available in the classpath.

To resolve this error:

Add the required truststore files to the main application that uses the Kafka Connector
configurations.

## Troubleshooting clientDNSLookUp Property

Since Kafka Connector version 3.0.0, the default value for the **DNS Lookup** field was removed to
keep the connector backwards compatible. Kafka Connector keeps the same values as the previous
version, but now each value corresponds to the following properties:

<table><colgroup><col> <col></colgroup><thead><tr><th>Value</th><th>Property</th></tr></thead><tbody><tr><td><p>DEFAULT</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>USE_ALL_DNS_IPS</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></td><td><p>resolve_canonical_bootstrap_servers_only</p></td></tr></tbody></table>

## Troubleshooting Publishing Null Values

When the **Publish** operation receives null as input, the operation publishes an empty byte array.

To avoid this issue, the connector enables you to set the `mule.kafka.publish.useNull` boolean
system property.

- When set to `true`, the connector publishes a message with null as a value.

- When set to `false` or not set at all, the connector publishes a message with an empty byte array
  value.

For further information on how to configure properties, refer to the
[Use system properties](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system)

## Understand Commonly Thrown Exceptions

Here is a list of commonly thrown exception messages and how to interpret them:

- KAFKA:ALREADY\_COMMITTED

  A commit fails because the commit is already performed.

- KAFKA:AUTHENTICATION\_ERROR(SECURITY)

  An authentication error is thrown.

- KAFKA:AUTHORIZATION\_ERROR(CLIENT\_SECURITY)

  An authorization error occurred due to the client configuration or permissions.

- KAFKA:COMMIT\_FAILED

  A commit fails with an unrecoverable error.

- KAFKA:CONNECTIVITY

  Either a connection could not be established or there is a connectivity error.

- KAFKA:ILLEGAL\_STATE

  The consumer is not subscribed to any topics, and no manually assigned partitions are set to
  consume from.

- KAFKA:INPUT\_TOO\_LARGE

  The input is too large for the broker.

- KAFKA:INVALID\_ACK\_MODE

  An acknowledgement (ACK) or negative acknowledgement (NACK) operation is run over a consumer that
  is not in \`MANUAL\` mode.

- KAFKA:INVALID\_CONFIGURATION

  An invalid configuration value is set for the consumer or the producer.

- KAFKA:INVALID\_CONNECTION

  The referenced connection is invalid.

- KAFKA:INVALID\_INPUT

  The parameters set for the operation are incorrect.

- KAFKA:INVALID\_OFFSET

  The partition number set for the operation is less than \`0\`, is above the number of partitions,
  or is an invalid value.

- KAFKA:INVALID\_TOPIC

  The topic selected for the operation is invalid, and there is no automatic generation of said
  topic. This might also imply an invalid character in the topic name.

- KAFKA:INVALID\_TOPIC\_PARTITION

  The topic partition combination selected for the operation is invalid, and there is no automatic
  generation of topics. This might also imply an invalid character in the topic name, or a
  non-existing partition.

- KAFKA:NO\_POLL\_MADE

  No poll was made.

- KAFKA:NOT\_FOUND

  For consume operations, the poll does not bring any records for the configured timeouts.

- KAFKA:OUT\_OF\_RANGE

  There is no reset policy defined, and the offsets for these partitions are either larger or
  smaller than the range of offsets the server has for the given partition.

- KAFKA:PREVIOUS\_ASSIGNATION

  subscribe() is called previously with topics or pattern without a subsequent call to
  unsubscribe().

- KAFKA:PRODUCER\_FENCED

  Another producer with the same \`transactional.id\` is active.

- KAFKA:RETRY\_EXHAUSTED

  The maximum number of retries for the operation is reached.

- KAFKA:SESSION\_NOT\_FOUND

  No associated session is found when executing an operation.

- KAFKA:TIMEOUT

  A specific request takes longer than the configuration timeout values.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Apache Kafka Connector Reference](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-reference)

- [Salesforce Help](https://help.salesforce.com)

- [Salesforce Help](https://help.salesforce.com)

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=d43aa35c569f43c4c6a91b96a25880dbf4e385fc02792466bcd902723e7eb418 url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-troubleshooting.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Troubleshooting Apache Kafka Connector 4.11

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To troubleshoot Anypoint Connector for Apache Kafka (Apache Kafka Connector), become familiar with
the information about interpreting commonly thrown exception messages.

## Enable SSL Logging

Enable SSL logs to investigate an issue related to TLS communications.

Set your SSL log level depending on your required level of detail:

1.  Enable only SSL log details:

    `javax.net.debug=ssl`

2.  Enable only handshaking details. (The handshake protocol is a series of messages exchanged over
    the record protocol.)

    `javax.net.debug=ssl:handshake`

3.  Enable handshaking details and SSL details at the same time:

    `javax.net.debug=ssl, handshake`

4.  Enable the dumping of all details and traffic data:

    `javax.net.debug=all`

    > [!NOTE] This option is very verbose and under normal circumstances is not necessary.

> [!WARNING] SSL logging results in a performance impact for HTTPS or other TLS connections. Enable
> SSL logging only to troubleshoot a specific issue and do not enable it for extended periods. SSL
> logging produces a significant amount of log messages and can inundate your log file if it is left
> enabled and unattended.

To enable SSL logs:

Set the debug parameter as an argument in the runtime configuration for the application.

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and add `-M-Djavax.net.debug=ssl` in the **VM arguments** section.

## Enable Verbose Exception Logging

Enable verbose exception logs to show a complete stack trace of the error instead of the default
truncated output:

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and append the arguments in the **VM arguments** section to add the
    `mule.verbose.exceptions` property. For example:

    `-XX:PermSize=128M -XX:MaxPermSize=256M -Dmule.verbose.exceptions=true`

## Enable Verbose Logging

To get a better understanding of why an application’s interaction with Kafka Connector is failing,
temporarily enable verbose logging for the connector.

Remember to always disable enhanced verbosity after troubleshooting, because it can affect your Mule
application’s performance.

To enable verbose logging in the configuration file:

1.  Access Anypoint Studio and navigate to the **Package Explorer** view.

2.  Open your application’s project name.

3.  Open the `src/main/resources` folder.

4.  Open the `log4j2.xml` file inside the folder.

5.  Add an `<AsyncLogger>` tag inside the `<Loggers>` tag:

    ```xml
    			<Loggers>
    				...
    				<AsyncLogger name="com.mulesoft.connectors.kafka" level="DEBUG"/>
    				...
    			</Loggers>
    ```

6.  Save your application changes.

7.  Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule
    Application**.

## Enable FIPS Mode

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

## Failed to Load SSL Keystore

When the Kafka Connector configurations fail to load the required truststore files from the
classpath, you receive the following error:

```text
org.mule.runtime.api.connection.ConnectionException: Failed to load SSL keystore
```

The Kafka Connector configurations bundled with a dependency fail to establish connections even when
the required truststore files are available in the classpath.

To resolve this error:

Add the required truststore files to the main application that uses the Kafka Connector
configurations.

## Troubleshooting clientDNSLookUp Property

Since Kafka Connector version 3.0.0, the default value for the **DNS Lookup** field was removed to
keep the connector backwards compatible. Kafka Connector keeps the same values as the previous
version, but now each value corresponds to the following properties:

<table><colgroup><col> <col></colgroup><thead><tr><th>Value</th><th>Property</th></tr></thead><tbody><tr><td><p>DEFAULT</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>USE_ALL_DNS_IPS</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></td><td><p>resolve_canonical_bootstrap_servers_only</p></td></tr></tbody></table>

## Troubleshooting Publishing Null Values

When the **Publish** operation receives null as input, the operation publishes an empty byte array.

To avoid this issue, the connector enables you to set the `mule.kafka.publish.useNull` boolean
system property.

- When set to `true`, the connector publishes a message with null as a value.

- When set to `false` or not set at all, the connector publishes a message with an empty byte array
  value.

For further information on how to configure properties, refer to the
[Use system properties](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system)

## Understand Commonly Thrown Exceptions

Here is a list of commonly thrown exception messages and how to interpret them:

- KAFKA:ALREADY\_COMMITTED

  A commit fails because the commit is already performed.

- KAFKA:AUTHENTICATION\_ERROR(SECURITY)

  An authentication error is thrown.

- KAFKA:AUTHORIZATION\_ERROR(CLIENT\_SECURITY)

  An authorization error occurred due to the client configuration or permissions.

- KAFKA:COMMIT\_FAILED

  A commit fails with an unrecoverable error.

- KAFKA:CONNECTIVITY

  Either a connection could not be established or there is a connectivity error.

- KAFKA:ILLEGAL\_STATE

  The consumer is not subscribed to any topics, and no manually assigned partitions are set to
  consume from.

- KAFKA:INPUT\_TOO\_LARGE

  The input is too large for the broker.

- KAFKA:INVALID\_ACK\_MODE

  An acknowledgement (ACK) or negative acknowledgement (NACK) operation is run over a consumer that
  is not in \`MANUAL\` mode.

- KAFKA:INVALID\_CONFIGURATION

  An invalid configuration value is set for the consumer or the producer.

- KAFKA:INVALID\_CONNECTION

  The referenced connection is invalid.

- KAFKA:INVALID\_INPUT

  The parameters set for the operation are incorrect.

- KAFKA:INVALID\_OFFSET

  The partition number set for the operation is less than \`0\`, is above the number of partitions,
  or is an invalid value.

- KAFKA:INVALID\_TOPIC

  The topic selected for the operation is invalid, and there is no automatic generation of said
  topic. This might also imply an invalid character in the topic name.

- KAFKA:INVALID\_TOPIC\_PARTITION

  The topic partition combination selected for the operation is invalid, and there is no automatic
  generation of topics. This might also imply an invalid character in the topic name, or a
  non-existing partition.

- KAFKA:NO\_POLL\_MADE

  No poll was made.

- KAFKA:NOT\_FOUND

  For consume operations, the poll does not bring any records for the configured timeouts.

- KAFKA:OUT\_OF\_RANGE

  There is no reset policy defined, and the offsets for these partitions are either larger or
  smaller than the range of offsets the server has for the given partition.

- KAFKA:PREVIOUS\_ASSIGNATION

  subscribe() is called previously with topics or pattern without a subsequent call to
  unsubscribe().

- KAFKA:PRODUCER\_FENCED

  Another producer with the same \`transactional.id\` is active.

- KAFKA:RETRY\_EXHAUSTED

  The maximum number of retries for the operation is reached.

- KAFKA:SESSION\_NOT\_FOUND

  No associated session is found when executing an operation.

- KAFKA:TIMEOUT

  A specific request takes longer than the configuration timeout values.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Apache Kafka Connector Reference](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-reference)

- [Salesforce Help](https://help.salesforce.com)

- [Salesforce Help](https://help.salesforce.com)

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=f46c64f5a47190e1f74075a7087d3164f7fe0c2a9f92a709b4ca02dc67c3a2ba url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-troubleshooting.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Troubleshooting Apache Kafka Connector 4.12

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To troubleshoot Anypoint Connector for Apache Kafka (Apache Kafka Connector), become familiar with
the information about interpreting commonly thrown exception messages.

## Enable SSL Logging

Enable SSL logs to investigate an issue related to TLS communications.

Set your SSL log level depending on your required level of detail:

1.  Enable only SSL log details:

    `javax.net.debug=ssl`

2.  Enable only handshaking details. (The handshake protocol is a series of messages exchanged over
    the record protocol.)

    `javax.net.debug=ssl:handshake`

3.  Enable handshaking details and SSL details at the same time:

    `javax.net.debug=ssl, handshake`

4.  Enable the dumping of all details and traffic data:

    `javax.net.debug=all`

    > [!NOTE] This option is very verbose and under normal circumstances is not necessary.

> [!WARNING] SSL logging results in a performance impact for HTTPS or other TLS connections. Enable
> SSL logging only to troubleshoot a specific issue and do not enable it for extended periods. SSL
> logging produces a significant amount of log messages and can inundate your log file if it is left
> enabled and unattended.

To enable SSL logs:

Set the debug parameter as an argument in the runtime configuration for the application.

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and add `-M-Djavax.net.debug=ssl` in the **VM arguments** section.

## Enable Verbose Exception Logging

Enable verbose exception logs to show a complete stack trace of the error instead of the default
truncated output:

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and append the arguments in the **VM arguments** section to add the
    `mule.verbose.exceptions` property. For example:

    `-XX:PermSize=128M -XX:MaxPermSize=256M -Dmule.verbose.exceptions=true`

## Enable Verbose Logging

To get a better understanding of why an application’s interaction with Kafka Connector is failing,
temporarily enable verbose logging for the connector.

Remember to always disable enhanced verbosity after troubleshooting, because it can affect your Mule
application’s performance.

To enable verbose logging in the configuration file:

1.  Access Anypoint Studio and navigate to the **Package Explorer** view.

2.  Open your application’s project name.

3.  Open the `src/main/resources` folder.

4.  Open the `log4j2.xml` file inside the folder.

5.  Add an `<AsyncLogger>` tag inside the `<Loggers>` tag:

    ```xml
    			<Loggers>
    				...
    				<AsyncLogger name="com.mulesoft.connectors.kafka" level="DEBUG"/>
    				...
    			</Loggers>
    ```

6.  Save your application changes.

7.  Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule
    Application**.

## Enable FIPS Mode

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

## Failed to Load SSL Keystore

When the Kafka Connector configurations fail to load the required truststore files from the
classpath, you receive the following error:

```text
org.mule.runtime.api.connection.ConnectionException: Failed to load SSL keystore
```

The Kafka Connector configurations bundled with a dependency fail to establish connections even when
the required truststore files are available in the classpath.

To resolve this error:

Add the required truststore files to the main application that uses the Kafka Connector
configurations.

## Troubleshooting clientDNSLookUp Property

Since Kafka Connector version 3.0.0, the default value for the **DNS Lookup** field was removed to
keep the connector backwards compatible. Kafka Connector keeps the same values as the previous
version, but now each value corresponds to the following properties:

<table><colgroup><col> <col></colgroup><thead><tr><th>Value</th><th>Property</th></tr></thead><tbody><tr><td><p>DEFAULT</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>USE_ALL_DNS_IPS</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></td><td><p>resolve_canonical_bootstrap_servers_only</p></td></tr></tbody></table>

## Troubleshooting Publishing Null Values

When the **Publish** operation receives null as input, the operation publishes an empty byte array.

To avoid this issue, the connector enables you to set the `mule.kafka.publish.useNull` boolean
system property.

- When set to `true`, the connector publishes a message with null as a value.

- When set to `false` or not set at all, the connector publishes a message with an empty byte array
  value.

For further information on how to configure properties, refer to the
[Use system properties](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system)

## Understand Commonly Thrown Exceptions

Here is a list of commonly thrown exception messages and how to interpret them:

- KAFKA:ALREADY\_COMMITTED

  A commit fails because the commit is already performed.

- KAFKA:AUTHENTICATION\_ERROR(SECURITY)

  An authentication error is thrown.

- KAFKA:AUTHORIZATION\_ERROR(CLIENT\_SECURITY)

  An authorization error occurred due to the client configuration or permissions.

- KAFKA:COMMIT\_FAILED

  A commit fails with an unrecoverable error.

- KAFKA:CONNECTIVITY

  Either a connection could not be established or there is a connectivity error.

- KAFKA:ILLEGAL\_STATE

  The consumer is not subscribed to any topics, and no manually assigned partitions are set to
  consume from.

- KAFKA:INPUT\_TOO\_LARGE

  The input is too large for the broker.

- KAFKA:INVALID\_ACK\_MODE

  An acknowledgement (ACK) or negative acknowledgement (NACK) operation is run over a consumer that
  is not in \`MANUAL\` mode.

- KAFKA:INVALID\_CONFIGURATION

  An invalid configuration value is set for the consumer or the producer.

- KAFKA:INVALID\_CONNECTION

  The referenced connection is invalid.

- KAFKA:INVALID\_INPUT

  The parameters set for the operation are incorrect.

- KAFKA:INVALID\_OFFSET

  The partition number set for the operation is less than \`0\`, is above the number of partitions,
  or is an invalid value.

- KAFKA:INVALID\_TOPIC

  The topic selected for the operation is invalid, and there is no automatic generation of said
  topic. This might also imply an invalid character in the topic name.

- KAFKA:INVALID\_TOPIC\_PARTITION

  The topic partition combination selected for the operation is invalid, and there is no automatic
  generation of topics. This might also imply an invalid character in the topic name, or a
  non-existing partition.

- KAFKA:NO\_POLL\_MADE

  No poll was made.

- KAFKA:NOT\_FOUND

  For consume operations, the poll does not bring any records for the configured timeouts.

- KAFKA:OUT\_OF\_RANGE

  There is no reset policy defined, and the offsets for these partitions are either larger or
  smaller than the range of offsets the server has for the given partition.

- KAFKA:PREVIOUS\_ASSIGNATION

  subscribe() is called previously with topics or pattern without a subsequent call to
  unsubscribe().

- KAFKA:PRODUCER\_FENCED

  Another producer with the same \`transactional.id\` is active.

- KAFKA:RETRY\_EXHAUSTED

  The maximum number of retries for the operation is reached.

- KAFKA:SESSION\_NOT\_FOUND

  No associated session is found when executing an operation.

- KAFKA:TIMEOUT

  A specific request takes longer than the configuration timeout values.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Apache Kafka Connector Reference](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-reference)

- [Salesforce Help](https://help.salesforce.com)

- [Salesforce Help](https://help.salesforce.com)

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=5b311bcaff81d9e78ed16d20cbffd60a98d05fcc58d73f5baef35a3a9492f9db url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-troubleshooting.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Troubleshooting Apache Kafka Connector 4.13

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To troubleshoot Anypoint Connector for Apache Kafka (Apache Kafka Connector), become familiar with
the information about interpreting commonly thrown exception messages.

## Enable SSL Logging

Enable SSL logs to investigate an issue related to TLS communications.

Set your SSL log level depending on your required level of detail:

1.  Enable only SSL log details:

    `javax.net.debug=ssl`

2.  Enable only handshaking details. (The handshake protocol is a series of messages exchanged over
    the record protocol.)

    `javax.net.debug=ssl:handshake`

3.  Enable handshaking details and SSL details at the same time:

    `javax.net.debug=ssl, handshake`

4.  Enable the dumping of all details and traffic data:

    `javax.net.debug=all`

    > [!NOTE] This option is very verbose and under normal circumstances is not necessary.

> [!WARNING] SSL logging results in a performance impact for HTTPS or other TLS connections. Enable
> SSL logging only to troubleshoot a specific issue and do not enable it for extended periods. SSL
> logging produces a significant amount of log messages and can inundate your log file if it is left
> enabled and unattended.

To enable SSL logs:

Set the debug parameter as an argument in the runtime configuration for the application.

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and add `-M-Djavax.net.debug=ssl` in the **VM arguments** section.

## Enable Verbose Exception Logging

Enable verbose exception logs to show a complete stack trace of the error instead of the default
truncated output:

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and append the arguments in the **VM arguments** section to add the
    `mule.verbose.exceptions` property. For example:

    `-XX:PermSize=128M -XX:MaxPermSize=256M -Dmule.verbose.exceptions=true`

## Enable Verbose Logging

To get a better understanding of why an application’s interaction with Kafka Connector is failing,
temporarily enable verbose logging for the connector.

Remember to always disable enhanced verbosity after troubleshooting, because it can affect your Mule
application’s performance.

To enable verbose logging in the configuration file:

1.  Access Anypoint Studio and navigate to the **Package Explorer** view.

2.  Open your application’s project name.

3.  Open the `src/main/resources` folder.

4.  Open the `log4j2.xml` file inside the folder.

5.  Add an `<AsyncLogger>` tag inside the `<Loggers>` tag:

    ```xml
    			<Loggers>
    				...
    				<AsyncLogger name="com.mulesoft.connectors.kafka" level="DEBUG"/>
    				...
    			</Loggers>
    ```

6.  Save your application changes.

7.  Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule
    Application**.

## Enable FIPS Mode

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

## Failed to Load SSL Keystore

When the Kafka Connector configurations fail to load the required truststore files from the
classpath, you receive the following error:

```text
org.mule.runtime.api.connection.ConnectionException: Failed to load SSL keystore
```

The Kafka Connector configurations bundled with a dependency fail to establish connections even when
the required truststore files are available in the classpath.

To resolve this error:

Add the required truststore files to the main application that uses the Kafka Connector
configurations.

## Troubleshooting clientDNSLookUp Property

Since Kafka Connector version 3.0.0, the default value for the **DNS Lookup** field was removed to
keep the connector backwards compatible. Kafka Connector keeps the same values as the previous
version, but now each value corresponds to the following properties:

<table><colgroup><col> <col></colgroup><thead><tr><th>Value</th><th>Property</th></tr></thead><tbody><tr><td><p>DEFAULT</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>USE_ALL_DNS_IPS</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></td><td><p>resolve_canonical_bootstrap_servers_only</p></td></tr></tbody></table>

## Troubleshooting Publishing Null Values

When the **Publish** operation receives null as input, the operation publishes an empty byte array.

To avoid this issue, the connector enables you to set the `mule.kafka.publish.useNull` boolean
system property.

- When set to `true`, the connector publishes a message with null as a value.

- When set to `false` or not set at all, the connector publishes a message with an empty byte array
  value.

For further information on how to configure properties, refer to the
[Use system properties](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system)

## Understand Commonly Thrown Exceptions

Here is a list of commonly thrown exception messages and how to interpret them:

- KAFKA:ALREADY\_COMMITTED

  A commit fails because the commit is already performed.

- KAFKA:AUTHENTICATION\_ERROR(SECURITY)

  An authentication error is thrown.

- KAFKA:AUTHORIZATION\_ERROR(CLIENT\_SECURITY)

  An authorization error occurred due to the client configuration or permissions.

- KAFKA:COMMIT\_FAILED

  A commit fails with an unrecoverable error.

- KAFKA:CONNECTIVITY

  Either a connection could not be established or there is a connectivity error.

- KAFKA:ILLEGAL\_STATE

  The consumer is not subscribed to any topics, and no manually assigned partitions are set to
  consume from.

- KAFKA:INPUT\_TOO\_LARGE

  The input is too large for the broker.

- KAFKA:INVALID\_ACK\_MODE

  An acknowledgement (ACK) or negative acknowledgement (NACK) operation is run over a consumer that
  is not in \`MANUAL\` mode.

- KAFKA:INVALID\_CONFIGURATION

  An invalid configuration value is set for the consumer or the producer.

- KAFKA:INVALID\_CONNECTION

  The referenced connection is invalid.

- KAFKA:INVALID\_INPUT

  The parameters set for the operation are incorrect.

- KAFKA:INVALID\_OFFSET

  The partition number set for the operation is less than \`0\`, is above the number of partitions,
  or is an invalid value.

- KAFKA:INVALID\_TOPIC

  The topic selected for the operation is invalid, and there is no automatic generation of said
  topic. This might also imply an invalid character in the topic name.

- KAFKA:INVALID\_TOPIC\_PARTITION

  The topic partition combination selected for the operation is invalid, and there is no automatic
  generation of topics. This might also imply an invalid character in the topic name, or a
  non-existing partition.

- KAFKA:NO\_POLL\_MADE

  No poll was made.

- KAFKA:NOT\_FOUND

  For consume operations, the poll does not bring any records for the configured timeouts.

- KAFKA:OUT\_OF\_RANGE

  There is no reset policy defined, and the offsets for these partitions are either larger or
  smaller than the range of offsets the server has for the given partition.

- KAFKA:PREVIOUS\_ASSIGNATION

  subscribe() is called previously with topics or pattern without a subsequent call to
  unsubscribe().

- KAFKA:PRODUCER\_FENCED

  Another producer with the same \`transactional.id\` is active.

- KAFKA:RETRY\_EXHAUSTED

  The maximum number of retries for the operation is reached.

- KAFKA:SESSION\_NOT\_FOUND

  No associated session is found when executing an operation.

- KAFKA:TIMEOUT

  A specific request takes longer than the configuration timeout values.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Apache Kafka Connector Reference](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-reference)

- [Salesforce Help](https://help.salesforce.com)

- [Salesforce Help](https://help.salesforce.com)

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=ea04f7f5da1ab42220cc4558777c70a7452b50b42e51638474da50f94cb799b6 url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-troubleshooting.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Troubleshooting Apache Kafka Connector 4.14

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To troubleshoot Anypoint Connector for Apache Kafka (Apache Kafka Connector), become familiar with
the information about interpreting commonly thrown exception messages.

## Enable SSL Logging

Enable SSL logs to investigate an issue related to TLS communications.

Set your SSL log level depending on your required level of detail:

1.  Enable only SSL log details:

    `javax.net.debug=ssl`

2.  Enable only handshaking details. (The handshake protocol is a series of messages exchanged over
    the record protocol.)

    `javax.net.debug=ssl:handshake`

3.  Enable handshaking details and SSL details at the same time:

    `javax.net.debug=ssl, handshake`

4.  Enable the dumping of all details and traffic data:

    `javax.net.debug=all`

    > [!NOTE] This option is very verbose and under normal circumstances is not necessary.

> [!WARNING] SSL logging results in a performance impact for HTTPS or other TLS connections. Enable
> SSL logging only to troubleshoot a specific issue and do not enable it for extended periods. SSL
> logging produces a significant amount of log messages and can inundate your log file if it is left
> enabled and unattended.

To enable SSL logs:

Set the debug parameter as an argument in the runtime configuration for the application.

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and add `-M-Djavax.net.debug=ssl` in the **VM arguments** section.

## Enable Verbose Exception Logging

Enable verbose exception logs to show a complete stack trace of the error instead of the default
truncated output:

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and append the arguments in the **VM arguments** section to add the
    `mule.verbose.exceptions` property. For example:

    `-XX:PermSize=128M -XX:MaxPermSize=256M -Dmule.verbose.exceptions=true`

## Enable Verbose Logging

To get a better understanding of why an application’s interaction with Kafka Connector is failing,
temporarily enable verbose logging for the connector.

Remember to always disable enhanced verbosity after troubleshooting, because it can affect your Mule
application’s performance.

To enable verbose logging in the configuration file:

1.  Access Anypoint Studio and navigate to the **Package Explorer** view.

2.  Open your application’s project name.

3.  Open the `src/main/resources` folder.

4.  Open the `log4j2.xml` file inside the folder.

5.  Add an `<AsyncLogger>` tag inside the `<Loggers>` tag:

    ```xml
    			<Loggers>
    				...
    				<AsyncLogger name="com.mulesoft.connectors.kafka" level="DEBUG"/>
    				...
    			</Loggers>
    ```

6.  Save your application changes.

7.  Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule
    Application**.

## Enable FIPS Mode

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

## Failed to Load SSL Keystore

When the Kafka Connector configurations fail to load the required truststore files from the
classpath, you receive the following error:

```text
org.mule.runtime.api.connection.ConnectionException: Failed to load SSL keystore
```

The Kafka Connector configurations bundled with a dependency fail to establish connections even when
the required truststore files are available in the classpath.

To resolve this error:

Add the required truststore files to the main application that uses the Kafka Connector
configurations.

## Troubleshooting clientDNSLookUp Property

Since Kafka Connector version 3.0.0, the default value for the **DNS Lookup** field was removed to
keep the connector backwards compatible. Kafka Connector keeps the same values as the previous
version, but now each value corresponds to the following properties:

<table><colgroup><col> <col></colgroup><thead><tr><th>Value</th><th>Property</th></tr></thead><tbody><tr><td><p>DEFAULT</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>USE_ALL_DNS_IPS</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></td><td><p>resolve_canonical_bootstrap_servers_only</p></td></tr></tbody></table>

## Troubleshooting Publishing Null Values

When the **Publish** operation receives null as input, the operation publishes an empty byte array.

To avoid this issue, the connector enables you to set the `mule.kafka.publish.useNull` boolean
system property.

- When set to `true`, the connector publishes a message with null as a value.

- When set to `false` or not set at all, the connector publishes a message with an empty byte array
  value.

For further information on how to configure properties, refer to the
[Use system properties](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system)

## Understand Commonly Thrown Exceptions

Here is a list of commonly thrown exception messages and how to interpret them:

- KAFKA:ALREADY\_COMMITTED

  A commit fails because the commit is already performed.

- KAFKA:AUTHENTICATION\_ERROR(SECURITY)

  An authentication error is thrown.

- KAFKA:AUTHORIZATION\_ERROR(CLIENT\_SECURITY)

  An authorization error occurred due to the client configuration or permissions.

- KAFKA:COMMIT\_FAILED

  A commit fails with an unrecoverable error.

- KAFKA:CONNECTIVITY

  Either a connection could not be established or there is a connectivity error.

- KAFKA:ILLEGAL\_STATE

  The consumer is not subscribed to any topics, and no manually assigned partitions are set to
  consume from.

- KAFKA:INPUT\_TOO\_LARGE

  The input is too large for the broker.

- KAFKA:INVALID\_ACK\_MODE

  An acknowledgement (ACK) or negative acknowledgement (NACK) operation is run over a consumer that
  is not in \`MANUAL\` mode.

- KAFKA:INVALID\_CONFIGURATION

  An invalid configuration value is set for the consumer or the producer.

- KAFKA:INVALID\_CONNECTION

  The referenced connection is invalid.

- KAFKA:INVALID\_INPUT

  The parameters set for the operation are incorrect.

- KAFKA:INVALID\_OFFSET

  The partition number set for the operation is less than \`0\`, is above the number of partitions,
  or is an invalid value.

- KAFKA:INVALID\_TOPIC

  The topic selected for the operation is invalid, and there is no automatic generation of said
  topic. This might also imply an invalid character in the topic name.

- KAFKA:INVALID\_TOPIC\_PARTITION

  The topic partition combination selected for the operation is invalid, and there is no automatic
  generation of topics. This might also imply an invalid character in the topic name, or a
  non-existing partition.

- KAFKA:NO\_POLL\_MADE

  No poll was made.

- KAFKA:NOT\_FOUND

  For consume operations, the poll does not bring any records for the configured timeouts.

- KAFKA:OUT\_OF\_RANGE

  There is no reset policy defined, and the offsets for these partitions are either larger or
  smaller than the range of offsets the server has for the given partition.

- KAFKA:PREVIOUS\_ASSIGNATION

  subscribe() is called previously with topics or pattern without a subsequent call to
  unsubscribe().

- KAFKA:PRODUCER\_FENCED

  Another producer with the same \`transactional.id\` is active.

- KAFKA:RETRY\_EXHAUSTED

  The maximum number of retries for the operation is reached.

- KAFKA:SESSION\_NOT\_FOUND

  No associated session is found when executing an operation.

- KAFKA:TIMEOUT

  A specific request takes longer than the configuration timeout values.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Apache Kafka Connector Reference](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-reference)

- [Salesforce Help](https://help.salesforce.com)

- [Salesforce Help](https://help.salesforce.com)

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=aa8ad380655b8aac30350dafc37fe2b00ec7c6a69cb31bd906e33ff310e0b37e url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-troubleshooting.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Troubleshooting Apache Kafka Connector 4.15

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To troubleshoot Anypoint Connector for Apache Kafka (Apache Kafka Connector), become familiar with
the information about interpreting commonly thrown exception messages.

## Enable SSL Logging

Enable SSL logs to investigate an issue related to TLS communications.

Set your SSL log level depending on your required level of detail:

1.  Enable only SSL log details:

    `javax.net.debug=ssl`

2.  Enable only handshaking details. (The handshake protocol is a series of messages exchanged over
    the record protocol.)

    `javax.net.debug=ssl:handshake`

3.  Enable handshaking details and SSL details at the same time:

    `javax.net.debug=ssl, handshake`

4.  Enable the dumping of all details and traffic data:

    `javax.net.debug=all`

    > [!NOTE] This option is very verbose and under normal circumstances is not necessary.

> [!WARNING] SSL logging results in a performance impact for HTTPS or other TLS connections. Enable
> SSL logging only to troubleshoot a specific issue and do not enable it for extended periods. SSL
> logging produces a significant amount of log messages and can inundate your log file if it is left
> enabled and unattended.

To enable SSL logs:

Set the debug parameter as an argument in the runtime configuration for the application.

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and add `-M-Djavax.net.debug=ssl` in the **VM arguments** section.

## Enable Verbose Exception Logging

Enable verbose exception logs to show a complete stack trace of the error instead of the default
truncated output:

1.  In Studio, right-click on the project and select **Run > Run Configurations**.

2.  Go to the **Arguments** tab and append the arguments in the **VM arguments** section to add the
    `mule.verbose.exceptions` property. For example:

    `-XX:PermSize=128M -XX:MaxPermSize=256M -Dmule.verbose.exceptions=true`

## Enable Verbose Logging

To get a better understanding of why an application’s interaction with Kafka Connector is failing,
temporarily enable verbose logging for the connector.

Remember to always disable enhanced verbosity after troubleshooting, because it can affect your Mule
application’s performance.

To enable verbose logging in the configuration file:

1.  Access Anypoint Studio and navigate to the **Package Explorer** view.

2.  Open your application’s project name.

3.  Open the `src/main/resources` folder.

4.  Open the `log4j2.xml` file inside the folder.

5.  Add an `<AsyncLogger>` tag inside the `<Loggers>` tag:

    ```xml
    			<Loggers>
    				...
    				<AsyncLogger name="com.mulesoft.connectors.kafka" level="DEBUG"/>
    				...
    			</Loggers>
    ```

6.  Save your application changes.

7.  Click the project name in **Package Explorer** and then click **Run** > **Run As** > **Mule
    Application**.

## Enable FIPS Mode

Enable FIPS mode by setting the
`com.mulesoft.connectors.allow-registration-of-sasl-security-provider-in-fips=true` flag to true.
This adds the `com.sun.security.sasl.Provider` security provider in the FIPS environment.

## Failed to Load SSL Keystore

When the Kafka Connector configurations fail to load the required truststore files from the
classpath, you receive the following error:

```text
org.mule.runtime.api.connection.ConnectionException: Failed to load SSL keystore
```

The Kafka Connector configurations bundled with a dependency fail to establish connections even when
the required truststore files are available in the classpath.

To resolve this error:

Add the required truststore files to the main application that uses the Kafka Connector
configurations.

## Troubleshooting clientDNSLookUp Property

Since Kafka Connector version 3.0.0, the default value for the **DNS Lookup** field was removed to
keep the connector backwards compatible. Kafka Connector keeps the same values as the previous
version, but now each value corresponds to the following properties:

<table><colgroup><col> <col></colgroup><thead><tr><th>Value</th><th>Property</th></tr></thead><tbody><tr><td><p>DEFAULT</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>USE_ALL_DNS_IPS</p></td><td><p>use_all_dns_ips</p></td></tr><tr><td><p>RESOLVE_CANONICAL_BOOTSTRAP_SERVERS_ONLY</p></td><td><p>resolve_canonical_bootstrap_servers_only</p></td></tr></tbody></table>

## Troubleshooting Publishing Null Values

When the **Publish** operation receives null as input, the operation publishes an empty byte array.

To avoid this issue, the connector enables you to set the `mule.kafka.publish.useNull` boolean
system property.

- When set to `true`, the connector publishes a message with null as a value.

- When set to `false` or not set at all, the connector publishes a message with an empty byte array
  value.

For further information on how to configure properties, refer to the
[Use system properties](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system)

## Understand Commonly Thrown Exceptions

Here is a list of commonly thrown exception messages and how to interpret them:

- KAFKA:ALREADY\_COMMITTED

  A commit fails because the commit is already performed.

- KAFKA:AUTHENTICATION\_ERROR(SECURITY)

  An authentication error is thrown.

- KAFKA:AUTHORIZATION\_ERROR(CLIENT\_SECURITY)

  An authorization error occurred due to the client configuration or permissions.

- KAFKA:COMMIT\_FAILED

  A commit fails with an unrecoverable error.

- KAFKA:CONNECTIVITY

  Either a connection could not be established or there is a connectivity error.

- KAFKA:ILLEGAL\_STATE

  The consumer is not subscribed to any topics, and no manually assigned partitions are set to
  consume from.

- KAFKA:INPUT\_TOO\_LARGE

  The input is too large for the broker.

- KAFKA:INVALID\_ACK\_MODE

  An acknowledgement (ACK) or negative acknowledgement (NACK) operation is run over a consumer that
  is not in \`MANUAL\` mode.

- KAFKA:INVALID\_CONFIGURATION

  An invalid configuration value is set for the consumer or the producer.

- KAFKA:INVALID\_CONNECTION

  The referenced connection is invalid.

- KAFKA:INVALID\_INPUT

  The parameters set for the operation are incorrect.

- KAFKA:INVALID\_OFFSET

  The partition number set for the operation is less than \`0\`, is above the number of partitions,
  or is an invalid value.

- KAFKA:INVALID\_TOPIC

  The topic selected for the operation is invalid, and there is no automatic generation of said
  topic. This might also imply an invalid character in the topic name.

- KAFKA:INVALID\_TOPIC\_PARTITION

  The topic partition combination selected for the operation is invalid, and there is no automatic
  generation of topics. This might also imply an invalid character in the topic name, or a
  non-existing partition.

- KAFKA:NO\_POLL\_MADE

  No poll was made.

- KAFKA:NOT\_FOUND

  For consume operations, the poll does not bring any records for the configured timeouts.

- KAFKA:OUT\_OF\_RANGE

  There is no reset policy defined, and the offsets for these partitions are either larger or
  smaller than the range of offsets the server has for the given partition.

- KAFKA:PREVIOUS\_ASSIGNATION

  subscribe() is called previously with topics or pattern without a subsequent call to
  unsubscribe().

- KAFKA:PRODUCER\_FENCED

  Another producer with the same \`transactional.id\` is active.

- KAFKA:RETRY\_EXHAUSTED

  The maximum number of retries for the operation is reached.

- KAFKA:SESSION\_NOT\_FOUND

  No associated session is found when executing an operation.

- KAFKA:TIMEOUT

  A specific request takes longer than the configuration timeout values.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Apache Kafka Connector Reference](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-reference)

- [Salesforce Help](https://help.salesforce.com)

- [Salesforce Help](https://help.salesforce.com)

- [Known Issues](https://help.salesforce.com/s/issues)

<!-- document id=a80bcc2edf22ec0c2875eb7155aa04da678e826a89971680b66c243f50d7d7ec url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-upgrade-migrate.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Upgrading and Migrating Apache Kafka Connector to 4.x

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Upgrade Anypoint Connector for Apache Kafka (Apache Kafka Connector) to version 4.x.

## Supported Upgrade Paths

<table><colgroup><col> <col></colgroup><thead><tr><th>From Version</th><th>To Version</th></tr></thead><tbody><tr><td><div><div><p>3.2.x</p></div></div></td><td><div><div><p>4.x</p></div></div></td></tr></tbody></table>

## Changes in This Release

Apache Kafka Connector 4.x contains a lot of changes to improve efficiency, including new operations
to enable you to better understand how to use the connector.

All of the changes included in this version break backward compatibility.

This release contains the following changes:

- Four new operations with new parameters were added:

  - Commit  
    This operation commits the offsets associated with a message or batch of messages consumed in a
    Message Listener (Source) or in a Batch Message Listener (Source). This operation works only
    with MANUAL Ack mode.

  - Consume  
    This operation is used for receiving messages from one or more Kafka topics. The Consume
    operation works similarly to the Message Listener source, so all the operations that apply to
    the Message Listener source also apply to this operation.

  - Publish  
    This operation enables sending messages to a Kafka topic. It is non-blocking, and its behavior
    depends on specific values of the connection parameters. This operation supports transactions,
    so a transaction ID is randomly generated for the Kafka Producer.

  - Seek  
    This operation is used for setting the current offset of the consumer for a given topic and
    partition to the provided offset value.  
    See the [New Operations](#new_operations) table.

- The Message Listener replaces the Message Consumer source.  
  See the [Changed Sources](#changed_sources) table.

- Added a Batch Message Listener source, which works in a similar way as the Message Listener with
  the difference that it processes the list of messages instead of a single message at a time. The
  message list obtained in the poll is handled by the Mule flow as a single event.  
  See the [New Sources](#new_sources) table for information about the new parameters.

- Added different acknowledgment modes in the consumer configuration, including:

  - AUTO  
    Mule acknowledges the message only if the flow is finished successfully.

  - MANUAL  
    The user must manually acknowledge the message within the flow.

  - DUPS\_OK  
    Same as the AUTO mode, but the commit is made asynchronously, which can result in duplicate
    records.

  - IMMEDIATE  
    Mule automatically acknowledges the message upon receipt.

- There is now one plaintext connection type that supports transactions.

  In version 3.x of the connector, you could add a customizable set of configuration properties
  related to connections. In version 4.x of the connector, this feature was removed. The connector
  now has a set of connection types for which you can set properties.

## Changed Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Source</th><th>Earlier version</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Message Listener</p></td><td><p>Message consumer</p></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## New Operations

This release contains the following new operations:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Commit</p></td><td><div><div><p>Commits the offsets associated to a message or batch of messages consumed in a Message Listener.</p></div></div></td><td><div><div><p>Consumer commit key. The consumer commit key to use to commit the message.</p></div></div></td></tr><tr><td><p>Consume</p></td><td><div><div><p>Enables receiving messages from one or more Kafka topics. It works similarly to the Message Listener source, so all the operations that apply to the Message Listener source also apply to this operation.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Consumption timeout</p></li><li><p>Timeout time unit</p></li></ul></div></div></td></tr><tr><td><p>Publish</p></td><td><div><div><p>Enables sending messages to a Kafka topic, and is non-blocking. Its behavior depends on specific values of the connection parameters. This operation supports transactions, which means that a transaction ID is randomly generated for the Kafka producer and handled in the connection.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Key</p></li><li><p>Message</p></li><li><p>Headers</p></li></ul></div></div></td></tr><tr><td><p>Seek</p></td><td><div><div><p>Sets the current offset of the consumer for the given topic and partition to the provided offset value.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Offset (The offset to seek to)</p></li></ul></div></div></td></tr></tbody></table>

> [!NOTE] With the exception of the Commit operation, the flow will be blocked if the `timeout`
> parameter is not specified.

## New Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Batch Message Listener</p></td><td><div><div><p>Works in the same way as the Message Listener except that it processes the list of messages instead of processing a single message at a time. The message list that was obtained in the poll is handled by a flow as a single event, so the handling of concurrency is simpler than in the simple Message Listener. In other words, a commit of the messages happens for all the messages as a whole by calling the commit on the Kafka consumer.</p></div></div></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## Upgrade Prerequisites

Before you perform the upgrade, you must create a backup of your files, data, and configurations in
case you need to revert to the previous version.

## Upgrade Steps

Follow these steps to perform the upgrade to Apache Kafka Connector 4.0.x:

1.  In Studio, create a Mule project.

2.  In the Mule Palette view, click **Search in Exchange**.

3.  In Add Modules to Project, type 'Apache Kafka' in the search field.

4.  In Available modules, select **Apache Kafka Connector** and then click **Add**.

5.  Click **Finish**.  
    Anypoint Studio upgrades the connector automatically.

6.  Verify that the `kafka-connector` dependency version is `4.0.0` in the pom.xml.

## Post Upgrade Steps

After you install the latest version of the connector, follow these steps to complete the upgrade:

1.  In Anypoint Studio, verify that there are no errors in the **Problems** or **Console** views.

2.  Check the project pom.xml and verify that there are no problems.

3.  Test the connection and verify that the operations work.

## Troubleshooting

If there are problems with caching the parameters and caching the metadata, try restarting Anypoint
Studio.

### Reverting the Upgrade

If it is necessary to revert to the previous version of Apache Kafka Connector, in Anypoint Studio,
change the `kafka-connector` dependency version `4.0.0` in the project’s pom.xml to the previous
version.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=9378693db698b456c879d6e7536dc02fb6626c6c5d3fd4c7dbba82ffb1b43f5b url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-upgrade-migrate.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Upgrading and Migrating Apache Kafka Connector to 4.x

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Upgrade Anypoint Connector for Apache Kafka (Apache Kafka Connector) to version 4.x.

## Supported Upgrade Paths

<table><colgroup><col> <col></colgroup><thead><tr><th>From Version</th><th>To Version</th></tr></thead><tbody><tr><td><div><div><p>3.2.x</p></div></div></td><td><div><div><p>4.x</p></div></div></td></tr></tbody></table>

## Changes in This Release

Apache Kafka Connector 4.x contains a lot of changes to improve efficiency, including new operations
to enable you to better understand how to use the connector.

All of the changes included in this version break backward compatibility.

This release contains the following changes:

- Four new operations with new parameters were added:

  - Commit  
    This operation commits the offsets associated with a message or batch of messages consumed in a
    Message Listener (Source) or in a Batch Message Listener (Source). This operation works only
    with MANUAL Ack mode.

  - Consume  
    This operation is used for receiving messages from one or more Kafka topics. The Consume
    operation works similarly to the Message Listener source, so all the operations that apply to
    the Message Listener source also apply to this operation.

  - Publish  
    This operation enables sending messages to a Kafka topic. It is non-blocking, and its behavior
    depends on specific values of the connection parameters. This operation supports transactions,
    so a transaction ID is randomly generated for the Kafka Producer.

  - Seek  
    This operation is used for setting the current offset of the consumer for a given topic and
    partition to the provided offset value.  
    See the [New Operations](#new_operations) table.

- The Message Listener replaces the Message Consumer source.  
  See the [Changed Sources](#changed_sources) table.

- Added a Batch Message Listener source, which works in a similar way as the Message Listener with
  the difference that it processes the list of messages instead of a single message at a time. The
  message list obtained in the poll is handled by the Mule flow as a single event.  
  See the [New Sources](#new_sources) table for information about the new parameters.

- Added different acknowledgment modes in the consumer configuration, including:

  - AUTO  
    Mule acknowledges the message only if the flow is finished successfully.

  - MANUAL  
    The user must manually acknowledge the message within the flow.

  - DUPS\_OK  
    Same as the AUTO mode, but the commit is made asynchronously, which can result in duplicate
    records.

  - IMMEDIATE  
    Mule automatically acknowledges the message upon receipt.

- There is now one plaintext connection type that supports transactions.

  In version 3.x of the connector, you could add a customizable set of configuration properties
  related to connections. In version 4.x of the connector, this feature was removed. The connector
  now has a set of connection types for which you can set properties.

## Changed Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Source</th><th>Earlier version</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Message Listener</p></td><td><p>Message consumer</p></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## New Operations

This release contains the following new operations:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Commit</p></td><td><div><div><p>Commits the offsets associated to a message or batch of messages consumed in a Message Listener.</p></div></div></td><td><div><div><p>Consumer commit key. The consumer commit key to use to commit the message.</p></div></div></td></tr><tr><td><p>Consume</p></td><td><div><div><p>Enables receiving messages from one or more Kafka topics. It works similarly to the Message Listener source, so all the operations that apply to the Message Listener source also apply to this operation.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Consumption timeout</p></li><li><p>Timeout time unit</p></li></ul></div></div></td></tr><tr><td><p>Publish</p></td><td><div><div><p>Enables sending messages to a Kafka topic, and is non-blocking. Its behavior depends on specific values of the connection parameters. This operation supports transactions, which means that a transaction ID is randomly generated for the Kafka producer and handled in the connection.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Key</p></li><li><p>Message</p></li><li><p>Headers</p></li></ul></div></div></td></tr><tr><td><p>Seek</p></td><td><div><div><p>Sets the current offset of the consumer for the given topic and partition to the provided offset value.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Offset (The offset to seek to)</p></li></ul></div></div></td></tr></tbody></table>

> [!NOTE] With the exception of the Commit operation, the flow will be blocked if the `timeout`
> parameter is not specified.

## New Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Batch Message Listener</p></td><td><div><div><p>Works in the same way as the Message Listener except that it processes the list of messages instead of processing a single message at a time. The message list that was obtained in the poll is handled by a flow as a single event, so the handling of concurrency is simpler than in the simple Message Listener. In other words, a commit of the messages happens for all the messages as a whole by calling the commit on the Kafka consumer.</p></div></div></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## Upgrade Prerequisites

Before you perform the upgrade, you must create a backup of your files, data, and configurations in
case you need to revert to the previous version.

## Upgrade Steps

Follow these steps to perform the upgrade to Apache Kafka Connector 4.0.x:

1.  In Studio, create a Mule project.

2.  In the Mule Palette view, click **Search in Exchange**.

3.  In Add Modules to Project, type 'Apache Kafka' in the search field.

4.  In Available modules, select **Apache Kafka Connector** and then click **Add**.

5.  Click **Finish**.  
    Anypoint Studio upgrades the connector automatically.

6.  Verify that the `kafka-connector` dependency version is `4.0.0` in the pom.xml.

## Post Upgrade Steps

After you install the latest version of the connector, follow these steps to complete the upgrade:

1.  In Anypoint Studio, verify that there are no errors in the **Problems** or **Console** views.

2.  Check the project pom.xml and verify that there are no problems.

3.  Test the connection and verify that the operations work.

## Troubleshooting

If there are problems with caching the parameters and caching the metadata, try restarting Anypoint
Studio.

### Reverting the Upgrade

If it is necessary to revert to the previous version of Apache Kafka Connector, in Anypoint Studio,
change the `kafka-connector` dependency version `4.0.0` in the project’s pom.xml to the previous
version.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=1d0c22020dea6dc401da5a65703926b32a4d50e3971fca827a9d79a55003235d url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-upgrade-migrate.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Upgrading and Migrating Apache Kafka Connector to 4.x

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Upgrade Anypoint Connector for Apache Kafka (Apache Kafka Connector) to version 4.x.

## Supported Upgrade Paths

<table><colgroup><col> <col></colgroup><thead><tr><th>From Version</th><th>To Version</th></tr></thead><tbody><tr><td><div><div><p>3.2.x</p></div></div></td><td><div><div><p>4.x</p></div></div></td></tr></tbody></table>

## Changes in This Release

Apache Kafka Connector 4.x contains a lot of changes to improve efficiency, including new operations
to enable you to better understand how to use the connector.

All of the changes included in this version break backward compatibility.

This release contains the following changes:

- Four new operations with new parameters were added:

  - Commit  
    This operation commits the offsets associated with a message or batch of messages consumed in a
    Message Listener (Source) or in a Batch Message Listener (Source). This operation works only
    with MANUAL Ack mode.

  - Consume  
    This operation is used for receiving messages from one or more Kafka topics. The Consume
    operation works similarly to the Message Listener source, so all the operations that apply to
    the Message Listener source also apply to this operation.

  - Publish  
    This operation enables sending messages to a Kafka topic. It is non-blocking, and its behavior
    depends on specific values of the connection parameters. This operation supports transactions,
    so a transaction ID is randomly generated for the Kafka Producer.

  - Seek  
    This operation is used for setting the current offset of the consumer for a given topic and
    partition to the provided offset value.  
    See the [New Operations](#new_operations) table.

- The Message Listener replaces the Message Consumer source.  
  See the [Changed Sources](#changed_sources) table.

- Added a Batch Message Listener source, which works in a similar way as the Message Listener with
  the difference that it processes the list of messages instead of a single message at a time. The
  message list obtained in the poll is handled by the Mule flow as a single event.  
  See the [New Sources](#new_sources) table for information about the new parameters.

- Added different acknowledgment modes in the consumer configuration, including:

  - AUTO  
    Mule acknowledges the message only if the flow is finished successfully.

  - MANUAL  
    The user must manually acknowledge the message within the flow.

  - DUPS\_OK  
    Same as the AUTO mode, but the commit is made asynchronously, which can result in duplicate
    records.

  - IMMEDIATE  
    Mule automatically acknowledges the message upon receipt.

- There is now one plaintext connection type that supports transactions.

  In version 3.x of the connector, you could add a customizable set of configuration properties
  related to connections. In version 4.x of the connector, this feature was removed. The connector
  now has a set of connection types for which you can set properties.

## Changed Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Source</th><th>Earlier version</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Message Listener</p></td><td><p>Message consumer</p></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## New Operations

This release contains the following new operations:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Commit</p></td><td><div><div><p>Commits the offsets associated to a message or batch of messages consumed in a Message Listener.</p></div></div></td><td><div><div><p>Consumer commit key. The consumer commit key to use to commit the message.</p></div></div></td></tr><tr><td><p>Consume</p></td><td><div><div><p>Enables receiving messages from one or more Kafka topics. It works similarly to the Message Listener source, so all the operations that apply to the Message Listener source also apply to this operation.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Consumption timeout</p></li><li><p>Timeout time unit</p></li></ul></div></div></td></tr><tr><td><p>Publish</p></td><td><div><div><p>Enables sending messages to a Kafka topic, and is non-blocking. Its behavior depends on specific values of the connection parameters. This operation supports transactions, which means that a transaction ID is randomly generated for the Kafka producer and handled in the connection.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Key</p></li><li><p>Message</p></li><li><p>Headers</p></li></ul></div></div></td></tr><tr><td><p>Seek</p></td><td><div><div><p>Sets the current offset of the consumer for the given topic and partition to the provided offset value.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Offset (The offset to seek to)</p></li></ul></div></div></td></tr></tbody></table>

> [!NOTE] With the exception of the Commit operation, the flow will be blocked if the `timeout`
> parameter is not specified.

## New Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Batch Message Listener</p></td><td><div><div><p>Works in the same way as the Message Listener except that it processes the list of messages instead of processing a single message at a time. The message list that was obtained in the poll is handled by a flow as a single event, so the handling of concurrency is simpler than in the simple Message Listener. In other words, a commit of the messages happens for all the messages as a whole by calling the commit on the Kafka consumer.</p></div></div></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## Upgrade Prerequisites

Before you perform the upgrade, you must create a backup of your files, data, and configurations in
case you need to revert to the previous version.

## Upgrade Steps

Follow these steps to perform the upgrade to Apache Kafka Connector 4.0.x:

1.  In Studio, create a Mule project.

2.  In the Mule Palette view, click **Search in Exchange**.

3.  In Add Modules to Project, type 'Apache Kafka' in the search field.

4.  In Available modules, select **Apache Kafka Connector** and then click **Add**.

5.  Click **Finish**.  
    Anypoint Studio upgrades the connector automatically.

6.  Verify that the `kafka-connector` dependency version is `4.0.0` in the pom.xml.

## Post Upgrade Steps

After you install the latest version of the connector, follow these steps to complete the upgrade:

1.  In Anypoint Studio, verify that there are no errors in the **Problems** or **Console** views.

2.  Check the project pom.xml and verify that there are no problems.

3.  Test the connection and verify that the operations work.

## Troubleshooting

If there are problems with caching the parameters and caching the metadata, try restarting Anypoint
Studio.

### Reverting the Upgrade

If it is necessary to revert to the previous version of Apache Kafka Connector, in Anypoint Studio,
change the `kafka-connector` dependency version `4.0.0` in the project’s pom.xml to the previous
version.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=addebb328ad4d70c51a069a4e84a51c1fbb0e0ed823c32e9245fbc0eb5b269bc url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-upgrade-migrate.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Upgrading and Migrating Apache Kafka Connector to 4.x

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Upgrade Anypoint Connector for Apache Kafka (Apache Kafka Connector) to version 4.x.

## Supported Upgrade Paths

<table><colgroup><col> <col></colgroup><thead><tr><th>From Version</th><th>To Version</th></tr></thead><tbody><tr><td><div><div><p>3.2.x</p></div></div></td><td><div><div><p>4.x</p></div></div></td></tr></tbody></table>

## Changes in This Release

Apache Kafka Connector 4.x contains a lot of changes to improve efficiency, including new operations
to enable you to better understand how to use the connector.

All of the changes included in this version break backward compatibility.

This release contains the following changes:

- Four new operations with new parameters were added:

  - Commit  
    This operation commits the offsets associated with a message or batch of messages consumed in a
    Message Listener (Source) or in a Batch Message Listener (Source). This operation works only
    with MANUAL Ack mode.

  - Consume  
    This operation is used for receiving messages from one or more Kafka topics. The Consume
    operation works similarly to the Message Listener source, so all the operations that apply to
    the Message Listener source also apply to this operation.

  - Publish  
    This operation enables sending messages to a Kafka topic. It is non-blocking, and its behavior
    depends on specific values of the connection parameters. This operation supports transactions,
    so a transaction ID is randomly generated for the Kafka Producer.

  - Seek  
    This operation is used for setting the current offset of the consumer for a given topic and
    partition to the provided offset value.  
    See the [New Operations](#new_operations) table.

- The Message Listener replaces the Message Consumer source.  
  See the [Changed Sources](#changed_sources) table.

- Added a Batch Message Listener source, which works in a similar way as the Message Listener with
  the difference that it processes the list of messages instead of a single message at a time. The
  message list obtained in the poll is handled by the Mule flow as a single event.  
  See the [New Sources](#new_sources) table for information about the new parameters.

- Added different acknowledgment modes in the consumer configuration, including:

  - AUTO  
    Mule acknowledges the message only if the flow is finished successfully.

  - MANUAL  
    The user must manually acknowledge the message within the flow.

  - DUPS\_OK  
    Same as the AUTO mode, but the commit is made asynchronously, which can result in duplicate
    records.

  - IMMEDIATE  
    Mule automatically acknowledges the message upon receipt.

- There is now one plaintext connection type that supports transactions.

  In version 3.x of the connector, you could add a customizable set of configuration properties
  related to connections. In version 4.x of the connector, this feature was removed. The connector
  now has a set of connection types for which you can set properties.

## Changed Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Source</th><th>Earlier version</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Message Listener</p></td><td><p>Message consumer</p></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## New Operations

This release contains the following new operations:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Commit</p></td><td><div><div><p>Commits the offsets associated to a message or batch of messages consumed in a Message Listener.</p></div></div></td><td><div><div><p>Consumer commit key. The consumer commit key to use to commit the message.</p></div></div></td></tr><tr><td><p>Consume</p></td><td><div><div><p>Enables receiving messages from one or more Kafka topics. It works similarly to the Message Listener source, so all the operations that apply to the Message Listener source also apply to this operation.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Consumption timeout</p></li><li><p>Timeout time unit</p></li></ul></div></div></td></tr><tr><td><p>Publish</p></td><td><div><div><p>Enables sending messages to a Kafka topic, and is non-blocking. Its behavior depends on specific values of the connection parameters. This operation supports transactions, which means that a transaction ID is randomly generated for the Kafka producer and handled in the connection.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Key</p></li><li><p>Message</p></li><li><p>Headers</p></li></ul></div></div></td></tr><tr><td><p>Seek</p></td><td><div><div><p>Sets the current offset of the consumer for the given topic and partition to the provided offset value.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Offset (The offset to seek to)</p></li></ul></div></div></td></tr></tbody></table>

> [!NOTE] With the exception of the Commit operation, the flow will be blocked if the `timeout`
> parameter is not specified.

## New Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Batch Message Listener</p></td><td><div><div><p>Works in the same way as the Message Listener except that it processes the list of messages instead of processing a single message at a time. The message list that was obtained in the poll is handled by a flow as a single event, so the handling of concurrency is simpler than in the simple Message Listener. In other words, a commit of the messages happens for all the messages as a whole by calling the commit on the Kafka consumer.</p></div></div></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## Upgrade Prerequisites

Before you perform the upgrade, you must create a backup of your files, data, and configurations in
case you need to revert to the previous version.

## Upgrade Steps

Follow these steps to perform the upgrade to Apache Kafka Connector 4.0.x:

1.  In Studio, create a Mule project.

2.  In the Mule Palette view, click **Search in Exchange**.

3.  In Add Modules to Project, type 'Apache Kafka' in the search field.

4.  In Available modules, select **Apache Kafka Connector** and then click **Add**.

5.  Click **Finish**.  
    Anypoint Studio upgrades the connector automatically.

6.  Verify that the `kafka-connector` dependency version is `4.0.0` in the pom.xml.

## Post Upgrade Steps

After you install the latest version of the connector, follow these steps to complete the upgrade:

1.  In Anypoint Studio, verify that there are no errors in the **Problems** or **Console** views.

2.  Check the project pom.xml and verify that there are no problems.

3.  Test the connection and verify that the operations work.

## Troubleshooting

If there are problems with caching the parameters and caching the metadata, try restarting Anypoint
Studio.

### Reverting the Upgrade

If it is necessary to revert to the previous version of Apache Kafka Connector, in Anypoint Studio,
change the `kafka-connector` dependency version `4.0.0` in the project’s pom.xml to the previous
version.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=c59c0915e3e7283bb6b2f048a39259f420a432028db395f58b8e5c730eb76826 url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-upgrade-migrate.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Upgrading and Migrating Apache Kafka Connector to 4.x

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Upgrade Anypoint Connector for Apache Kafka (Apache Kafka Connector) to version 4.x.

## Supported Upgrade Paths

<table><colgroup><col> <col></colgroup><thead><tr><th>From Version</th><th>To Version</th></tr></thead><tbody><tr><td><div><div><p>3.2.x</p></div></div></td><td><div><div><p>4.x</p></div></div></td></tr></tbody></table>

## Changes in This Release

Apache Kafka Connector 4.x contains a lot of changes to improve efficiency, including new operations
to enable you to better understand how to use the connector.

All of the changes included in this version break backward compatibility.

This release contains the following changes:

- Four new operations with new parameters were added:

  - Commit  
    This operation commits the offsets associated with a message or batch of messages consumed in a
    Message Listener (Source) or in a Batch Message Listener (Source). This operation works only
    with MANUAL Ack mode.

  - Consume  
    This operation is used for receiving messages from one or more Kafka topics. The Consume
    operation works similarly to the Message Listener source, so all the operations that apply to
    the Message Listener source also apply to this operation.

  - Publish  
    This operation enables sending messages to a Kafka topic. It is non-blocking, and its behavior
    depends on specific values of the connection parameters. This operation supports transactions,
    so a transaction ID is randomly generated for the Kafka Producer.

  - Seek  
    This operation is used for setting the current offset of the consumer for a given topic and
    partition to the provided offset value.  
    See the [New Operations](#new_operations) table.

- The Message Listener replaces the Message Consumer source.  
  See the [Changed Sources](#changed_sources) table.

- Added a Batch Message Listener source, which works in a similar way as the Message Listener with
  the difference that it processes the list of messages instead of a single message at a time. The
  message list obtained in the poll is handled by the Mule flow as a single event.  
  See the [New Sources](#new_sources) table for information about the new parameters.

- Added different acknowledgment modes in the consumer configuration, including:

  - AUTO  
    Mule acknowledges the message only if the flow is finished successfully.

  - MANUAL  
    The user must manually acknowledge the message within the flow.

  - DUPS\_OK  
    Same as the AUTO mode, but the commit is made asynchronously, which can result in duplicate
    records.

  - IMMEDIATE  
    Mule automatically acknowledges the message upon receipt.

- There is now one plaintext connection type that supports transactions.

  In version 3.x of the connector, you could add a customizable set of configuration properties
  related to connections. In version 4.x of the connector, this feature was removed. The connector
  now has a set of connection types for which you can set properties.

## Changed Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Source</th><th>Earlier version</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Message Listener</p></td><td><p>Message consumer</p></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## New Operations

This release contains the following new operations:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Commit</p></td><td><div><div><p>Commits the offsets associated to a message or batch of messages consumed in a Message Listener.</p></div></div></td><td><div><div><p>Consumer commit key. The consumer commit key to use to commit the message.</p></div></div></td></tr><tr><td><p>Consume</p></td><td><div><div><p>Enables receiving messages from one or more Kafka topics. It works similarly to the Message Listener source, so all the operations that apply to the Message Listener source also apply to this operation.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Consumption timeout</p></li><li><p>Timeout time unit</p></li></ul></div></div></td></tr><tr><td><p>Publish</p></td><td><div><div><p>Enables sending messages to a Kafka topic, and is non-blocking. Its behavior depends on specific values of the connection parameters. This operation supports transactions, which means that a transaction ID is randomly generated for the Kafka producer and handled in the connection.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Key</p></li><li><p>Message</p></li><li><p>Headers</p></li></ul></div></div></td></tr><tr><td><p>Seek</p></td><td><div><div><p>Sets the current offset of the consumer for the given topic and partition to the provided offset value.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Offset (The offset to seek to)</p></li></ul></div></div></td></tr></tbody></table>

> [!NOTE] With the exception of the Commit operation, the flow will be blocked if the `timeout`
> parameter is not specified.

## New Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Batch Message Listener</p></td><td><div><div><p>Works in the same way as the Message Listener except that it processes the list of messages instead of processing a single message at a time. The message list that was obtained in the poll is handled by a flow as a single event, so the handling of concurrency is simpler than in the simple Message Listener. In other words, a commit of the messages happens for all the messages as a whole by calling the commit on the Kafka consumer.</p></div></div></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## Upgrade Prerequisites

Before you perform the upgrade, you must create a backup of your files, data, and configurations in
case you need to revert to the previous version.

## Upgrade Steps

Follow these steps to perform the upgrade to Apache Kafka Connector 4.0.x:

1.  In Studio, create a Mule project.

2.  In the Mule Palette view, click **Search in Exchange**.

3.  In Add Modules to Project, type 'Apache Kafka' in the search field.

4.  In Available modules, select **Apache Kafka Connector** and then click **Add**.

5.  Click **Finish**.  
    Anypoint Studio upgrades the connector automatically.

6.  Verify that the `kafka-connector` dependency version is `4.0.0` in the pom.xml.

## Post Upgrade Steps

After you install the latest version of the connector, follow these steps to complete the upgrade:

1.  In Anypoint Studio, verify that there are no errors in the **Problems** or **Console** views.

2.  Check the project pom.xml and verify that there are no problems.

3.  Test the connection and verify that the operations work.

## Troubleshooting

If there are problems with caching the parameters and caching the metadata, try restarting Anypoint
Studio.

### Reverting the Upgrade

If it is necessary to revert to the previous version of Apache Kafka Connector, in Anypoint Studio,
change the `kafka-connector` dependency version `4.0.0` in the project’s pom.xml to the previous
version.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=079facf7b44038d58556f6c9c5af58c3d1a3c13c4d901592d2c42a5611df9a60 url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-upgrade-migrate.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Upgrading and Migrating Apache Kafka Connector to 4.x

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Upgrade Anypoint Connector for Apache Kafka (Apache Kafka Connector) to version 4.x.

## Supported Upgrade Paths

<table><colgroup><col> <col></colgroup><thead><tr><th>From Version</th><th>To Version</th></tr></thead><tbody><tr><td><div><div><p>3.2.x</p></div></div></td><td><div><div><p>4.x</p></div></div></td></tr></tbody></table>

## Changes in This Release

Apache Kafka Connector 4.x contains a lot of changes to improve efficiency, including new operations
to enable you to better understand how to use the connector.

All of the changes included in this version break backward compatibility.

This release contains the following changes:

- Four new operations with new parameters were added:

  - Commit  
    This operation commits the offsets associated with a message or batch of messages consumed in a
    Message Listener (Source) or in a Batch Message Listener (Source). This operation works only
    with MANUAL Ack mode.

  - Consume  
    This operation is used for receiving messages from one or more Kafka topics. The Consume
    operation works similarly to the Message Listener source, so all the operations that apply to
    the Message Listener source also apply to this operation.

  - Publish  
    This operation enables sending messages to a Kafka topic. It is non-blocking, and its behavior
    depends on specific values of the connection parameters. This operation supports transactions,
    so a transaction ID is randomly generated for the Kafka Producer.

  - Seek  
    This operation is used for setting the current offset of the consumer for a given topic and
    partition to the provided offset value.  
    See the [New Operations](#new_operations) table.

- The Message Listener replaces the Message Consumer source.  
  See the [Changed Sources](#changed_sources) table.

- Added a Batch Message Listener source, which works in a similar way as the Message Listener with
  the difference that it processes the list of messages instead of a single message at a time. The
  message list obtained in the poll is handled by the Mule flow as a single event.  
  See the [New Sources](#new_sources) table for information about the new parameters.

- Added different acknowledgment modes in the consumer configuration, including:

  - AUTO  
    Mule acknowledges the message only if the flow is finished successfully.

  - MANUAL  
    The user must manually acknowledge the message within the flow.

  - DUPS\_OK  
    Same as the AUTO mode, but the commit is made asynchronously, which can result in duplicate
    records.

  - IMMEDIATE  
    Mule automatically acknowledges the message upon receipt.

- There is now one plaintext connection type that supports transactions.

  In version 3.x of the connector, you could add a customizable set of configuration properties
  related to connections. In version 4.x of the connector, this feature was removed. The connector
  now has a set of connection types for which you can set properties.

## Changed Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Source</th><th>Earlier version</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Message Listener</p></td><td><p>Message consumer</p></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## New Operations

This release contains the following new operations:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Commit</p></td><td><div><div><p>Commits the offsets associated to a message or batch of messages consumed in a Message Listener.</p></div></div></td><td><div><div><p>Consumer commit key. The consumer commit key to use to commit the message.</p></div></div></td></tr><tr><td><p>Consume</p></td><td><div><div><p>Enables receiving messages from one or more Kafka topics. It works similarly to the Message Listener source, so all the operations that apply to the Message Listener source also apply to this operation.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Consumption timeout</p></li><li><p>Timeout time unit</p></li></ul></div></div></td></tr><tr><td><p>Publish</p></td><td><div><div><p>Enables sending messages to a Kafka topic, and is non-blocking. Its behavior depends on specific values of the connection parameters. This operation supports transactions, which means that a transaction ID is randomly generated for the Kafka producer and handled in the connection.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Key</p></li><li><p>Message</p></li><li><p>Headers</p></li></ul></div></div></td></tr><tr><td><p>Seek</p></td><td><div><div><p>Sets the current offset of the consumer for the given topic and partition to the provided offset value.</p></div><div><div data-type="NOTE">You must specify the timeout parameter, or the flow will be blocked.</div></div></div></td><td><div><div><ul><li><p>Topic (The topic name)</p></li><li><p>Partition (The partition name)</p></li><li><p>Offset (The offset to seek to)</p></li></ul></div></div></td></tr></tbody></table>

> [!NOTE] With the exception of the Commit operation, the flow will be blocked if the `timeout`
> parameter is not specified.

## New Sources

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Kafka Operation</th><th>Description</th><th>Parameters</th></tr></thead><tbody><tr><td><p>Batch Message Listener</p></td><td><div><div><p>Works in the same way as the Message Listener except that it processes the list of messages instead of processing a single message at a time. The message list that was obtained in the poll is handled by a flow as a single event, so the handling of concurrency is simpler than in the simple Message Listener. In other words, a commit of the messages happens for all the messages as a whole by calling the commit on the Kafka consumer.</p></div></div></td><td><div><div><ul><li><p>Poll timeout</p></li><li><p>Poll timeout time unit</p></li><li><p>Acknowledgment mode</p></li><li><p>Number of parallel consumers</p></li></ul></div></div></td></tr></tbody></table>

## Upgrade Prerequisites

Before you perform the upgrade, you must create a backup of your files, data, and configurations in
case you need to revert to the previous version.

## Upgrade Steps

Follow these steps to perform the upgrade to Apache Kafka Connector 4.0.x:

1.  In Studio, create a Mule project.

2.  In the Mule Palette view, click **Search in Exchange**.

3.  In Add Modules to Project, type 'Apache Kafka' in the search field.

4.  In Available modules, select **Apache Kafka Connector** and then click **Add**.

5.  Click **Finish**.  
    Anypoint Studio upgrades the connector automatically.

6.  Verify that the `kafka-connector` dependency version is `4.0.0` in the pom.xml.

## Post Upgrade Steps

After you install the latest version of the connector, follow these steps to complete the upgrade:

1.  In Anypoint Studio, verify that there are no errors in the **Problems** or **Console** views.

2.  Check the project pom.xml and verify that there are no problems.

3.  Test the connection and verify that the operations work.

## Troubleshooting

If there are problems with caching the parameters and caching the metadata, try restarting Anypoint
Studio.

### Reverting the Upgrade

If it is necessary to revert to the previous version of Apache Kafka Connector, in Anypoint Studio,
change the `kafka-connector` dependency version `4.0.0` in the project’s pom.xml to the previous
version.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=d0e6e5e33d881455f0add51b2ca25e4ea58a8ee084aa7efd3f93cf56010781b4 url=/mulesoft/current/en-us/kafka-connector/4.10/kafka-connector-studio.md -->

---
product: Apache Kafka Connector
version: 4.10
---

# Using Anypoint Studio to Configure Apache Kafka 4.10

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In Anypoint Studio, add Anypoint Connector for Apache Kafka (Apache Kafka Connector) to a Mule
project, configure the connection to the Kafka cluster, and configure an input source for the
connector.

To configure a connector in Anypoint Studio:

1.  Add the connector to a Mule project.

2.  Configure the connector.

3.  Configure an input source for the connector.

## Add the Connector in Studio

1.  In Studio, create a Mule Project.

2.  In the Mule Palette, click **(X) Search in Exchange**.

3.  In **Add Modules to Project**, type the name of the connector in the search field.

4.  Click the connector name in **Available modules**.

5.  Click **Add**.

6.  Click **Finish**.

## Add the Connector Using Exchange

1.  In Studio, create a Mule Project.

2.  Click the Exchange **(X)** icon in the upper-left of the Studio task bar.

3.  In Exchange, click **Login** and supply your Anypoint Platform username and password.

4.  In Exchange, select **All assets** and search for `Apache Kafka`.

5.  Select the connector and click **Add to project**.

6.  Follow the prompts to add the connector to the Mule project.

## Consumer Configuration

You can create a consumer configuration global element to reference from Apache Kafka Connector.
This enables you to apply configuration details to multiple local elements in the flow.

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Consumer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

    <table><colgroup><col> <col> <col></colgroup><thead><tr><th>Connection Type</th><th>Field Name</th><th>Description</th></tr></thead><tbody><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka consumer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the consumer can use to connect to the Kafka cluster</p></td></tr><tr><td></td><td><p>Group ID</p></td><td><p>Default group ID for all the Kafka consumers that use this configuration</p></td></tr><tr><td><p>Consumer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kafka configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Consumer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Consumer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Consumer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Consumer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Producer Configuration

Create a producer configuration global element:

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Producer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

<table><colgroup><col> <col> <col></colgroup><tbody><tr><td><p>Connection Type</p></td><td><p>Field Name</p></td><td><p>Description</p></td></tr><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka producer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the producer can use to connect to the Kafka cluster</p></td></tr><tr><td><p>Producer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kerberos configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Producer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Producer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Producer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafa</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Producer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Configure TLS

To enable TLS for your app:

1.  Click the **TLS** tab to configure the truststore and keystore:

    - **Trust Store Configuration**

      - Path  
        Location of the truststore file.

      - Password  
        Password for the truststore file.

      - Type  
        File format of the truststore file.

      - Algorithm  
        Algorithm the truststore uses.

      - Insecure  
        Boolean that determines whether or not to validate the truststore. If set to `true`, no
        validation occurs. The default value is `false`.

    - **Key Store Configuration**

      - Type  
        Optionally specify the file format of the keystore file. The default value is `JKS`.

      - Path  
        Location of the keystore file. This is optional and can be used for two-way authentication
        for the connector.

      - Alias  
        Attribute that indicates the alias of the key to use when the keystore contains many private
        keys. If not defined, the first key in the file is used by default.

      - Key password  
        Key manager password, which is the password for the private key inside the keystore.

      - Password  
        Store password for the keystore file. This is optional and needed only if the **Key Store
        Location** is configured.

      - Algorithm  
        Algorithm used in the keystore.

        ![Kafka consumer configuration window](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-tls-studio-config.png)

## Configure the Commit Operation

1.  Drag the **Commit** operation to the Studio canvas.

2.  Configure the **Commit** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><tbody><tr><td><p>Name</p></td><td><p>Type</p></td><td><p>Description</p></td><td><p>Default Value</p></td><td><p>Required</p></td></tr><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>The name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Consumer commit key</p></td><td><div><div><p>String</p></div></div></td><td><p>The commitKey of the last poll. This operation is valid only when used inside a flow that is using one of the listener sources (<strong>Batch message listener</strong> or <strong>Message listener</strong>) which inserts this value as an attribute in the Mule event.</p></td><td></td><td><p>x</p></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-commit-studio-config-general.png)

3.  In the **Advanced** tab, configure the reconnection strategy.

## Configure the Consume Operation

1.  Drag the **Consume** operation to the Studio canvas.

2.  Configure the **Consume** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>The unit of time for the timeout property.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-consume-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configure to use repeatable streams.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression that evaluates the operation’s output. The outcome of the evaluation is stored in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Publish Operation

1.  Drag the **Publish** operation to the Studio canvas.

2.  Configure the **Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) The topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for producer config](/mulesoft/current/en-us/kafka-connector/4.10/_images/kafka-publish-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Bulk Publish Operation

1.  Drag the **Bulk Publish** operation to the Studio canvas.

2.  Configure the **Bulk Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of KafkaMessage</p></div></div></td><td><div><div><p>The list of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

For an example that builds the required `KafkaMessage` array and publishes multiple messages, see
[Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.10/kafka-connector-bulk-publish-example).

## Configure the Seek Operation

1.  Drag the **Seek** operation to the Studio canvas.

2.  Configure the **Seek** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which to perform the seek operation.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number for which to modify the offset.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure an Input Source

Configure an input source for the connector, such as the **Message Consumer** operation:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>Name of the topic from which to consume messages.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether to execute this source on only the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div><div><p>Configure to use repeatable streams.</p></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

You can also use the **Batch Message Listener** operation as an input source in Apache Kafka
Connector:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Connector Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>The amount of time to block.</p></div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>The time unit for the polling timeout. This combines with poll timeout to define the total timeout for the polling.</p></div></div></td></tr><tr><td><p><strong>Acknowledgment mode</strong></p></td><td><div><div><p>Declares the supported acknowledgment mode type.</p></div></div></td></tr><tr><td><p><strong>Amount of parallel consumers</strong></p></td><td><div><div><p>Declares how many consumers to use in parallel.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether this source should be executed only on the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><p>Define the streaming strategy.</p></div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=08c43dc62324a76860f2ca01134f1dec3d65957f7a5c6aa7ffc342226ac4130c url=/mulesoft/current/en-us/kafka-connector/4.11/kafka-connector-studio.md -->

---
product: Apache Kafka Connector
version: 4.11
---

# Using Anypoint Studio to Configure Apache Kafka 4.11

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In Anypoint Studio, add Anypoint Connector for Apache Kafka (Apache Kafka Connector) to a Mule
project, configure the connection to the Kafka cluster, and configure an input source for the
connector.

To configure a connector in Anypoint Studio:

1.  Add the connector to a Mule project.

2.  Configure the connector.

3.  Configure an input source for the connector.

## Add the Connector in Studio

1.  In Studio, create a Mule Project.

2.  In the Mule Palette, click **(X) Search in Exchange**.

3.  In **Add Modules to Project**, type the name of the connector in the search field.

4.  Click the connector name in **Available modules**.

5.  Click **Add**.

6.  Click **Finish**.

## Add the Connector Using Exchange

1.  In Studio, create a Mule Project.

2.  Click the Exchange **(X)** icon in the upper-left of the Studio task bar.

3.  In Exchange, click **Login** and supply your Anypoint Platform username and password.

4.  In Exchange, select **All assets** and search for `Apache Kafka`.

5.  Select the connector and click **Add to project**.

6.  Follow the prompts to add the connector to the Mule project.

## Consumer Configuration

You can create a consumer configuration global element to reference from Apache Kafka Connector.
This enables you to apply configuration details to multiple local elements in the flow.

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Consumer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

    <table><colgroup><col> <col> <col></colgroup><thead><tr><th>Connection Type</th><th>Field Name</th><th>Description</th></tr></thead><tbody><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka consumer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the consumer can use to connect to the Kafka cluster</p></td></tr><tr><td></td><td><p>Group ID</p></td><td><p>Default group ID for all the Kafka consumers that use this configuration</p></td></tr><tr><td><p>Consumer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kafka configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Consumer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Consumer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Consumer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Consumer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Producer Configuration

Create a producer configuration global element:

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Producer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

<table><colgroup><col> <col> <col></colgroup><tbody><tr><td><p>Connection Type</p></td><td><p>Field Name</p></td><td><p>Description</p></td></tr><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka producer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the producer can use to connect to the Kafka cluster</p></td></tr><tr><td><p>Producer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kerberos configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Producer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Producer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Producer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafa</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Producer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Configure TLS

To enable TLS for your app:

1.  Click the **TLS** tab to configure the truststore and keystore:

    - **Trust Store Configuration**

      - Path  
        Location of the truststore file.

      - Password  
        Password for the truststore file.

      - Type  
        File format of the truststore file.

      - Algorithm  
        Algorithm the truststore uses.

      - Insecure  
        Boolean that determines whether or not to validate the truststore. If set to `true`, no
        validation occurs. The default value is `false`.

    - **Key Store Configuration**

      - Type  
        Optionally specify the file format of the keystore file. The default value is `JKS`.

      - Path  
        Location of the keystore file. This is optional and can be used for two-way authentication
        for the connector.

      - Alias  
        Attribute that indicates the alias of the key to use when the keystore contains many private
        keys. If not defined, the first key in the file is used by default.

      - Key password  
        Key manager password, which is the password for the private key inside the keystore.

      - Password  
        Store password for the keystore file. This is optional and needed only if the **Key Store
        Location** is configured.

      - Algorithm  
        Algorithm used in the keystore.

        ![Kafka consumer configuration window](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-tls-studio-config.png)

## Configure the Commit Operation

1.  Drag the **Commit** operation to the Studio canvas.

2.  Configure the **Commit** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><tbody><tr><td><p>Name</p></td><td><p>Type</p></td><td><p>Description</p></td><td><p>Default Value</p></td><td><p>Required</p></td></tr><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>The name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Consumer commit key</p></td><td><div><div><p>String</p></div></div></td><td><p>The commitKey of the last poll. This operation is valid only when used inside a flow that is using one of the listener sources (<strong>Batch message listener</strong> or <strong>Message listener</strong>) which inserts this value as an attribute in the Mule event.</p></td><td></td><td><p>x</p></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-commit-studio-config-general.png)

3.  In the **Advanced** tab, configure the reconnection strategy.

## Configure the Consume Operation

1.  Drag the **Consume** operation to the Studio canvas.

2.  Configure the **Consume** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>The unit of time for the timeout property.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-consume-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configure to use repeatable streams.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression that evaluates the operation’s output. The outcome of the evaluation is stored in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Publish Operation

1.  Drag the **Publish** operation to the Studio canvas.

2.  Configure the **Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) The topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for producer config](/mulesoft/current/en-us/kafka-connector/4.11/_images/kafka-publish-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Bulk Publish Operation

1.  Drag the **Bulk Publish** operation to the Studio canvas.

2.  Configure the **Bulk Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of KafkaMessage</p></div></div></td><td><div><div><p>The list of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

For an example that builds the required `KafkaMessage` array and publishes multiple messages, see
[Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.11/kafka-connector-bulk-publish-example).

## Configure the Seek Operation

1.  Drag the **Seek** operation to the Studio canvas.

2.  Configure the **Seek** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which to perform the seek operation.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number for which to modify the offset.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure an Input Source

Configure an input source for the connector, such as the **Message Consumer** operation:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>Name of the topic from which to consume messages.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether to execute this source on only the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div><div><p>Configure to use repeatable streams.</p></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

You can also use the **Batch Message Listener** operation as an input source in Apache Kafka
Connector:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Connector Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>The amount of time to block.</p></div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>The time unit for the polling timeout. This combines with poll timeout to define the total timeout for the polling.</p></div></div></td></tr><tr><td><p><strong>Acknowledgment mode</strong></p></td><td><div><div><p>Declares the supported acknowledgment mode type.</p></div></div></td></tr><tr><td><p><strong>Amount of parallel consumers</strong></p></td><td><div><div><p>Declares how many consumers to use in parallel.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether this source should be executed only on the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><p>Define the streaming strategy.</p></div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=0bf411ddd4e946e3942618afa8f132bb2f93dfc03f99206873d4952755332869 url=/mulesoft/current/en-us/kafka-connector/4.12/kafka-connector-studio.md -->

---
product: Apache Kafka Connector
version: 4.12
---

# Using Anypoint Studio to Configure Apache Kafka 4.12

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In Anypoint Studio, add Anypoint Connector for Apache Kafka (Apache Kafka Connector) to a Mule
project, configure the connection to the Kafka cluster, and configure an input source for the
connector.

To configure a connector in Anypoint Studio:

1.  Add the connector to a Mule project.

2.  Configure the connector.

3.  Configure an input source for the connector.

## Add the Connector in Studio

1.  In Studio, create a Mule Project.

2.  In the Mule Palette, click **(X) Search in Exchange**.

3.  In **Add Modules to Project**, type the name of the connector in the search field.

4.  Click the connector name in **Available modules**.

5.  Click **Add**.

6.  Click **Finish**.

## Add the Connector Using Exchange

1.  In Studio, create a Mule Project.

2.  Click the Exchange **(X)** icon in the upper-left of the Studio task bar.

3.  In Exchange, click **Login** and supply your Anypoint Platform username and password.

4.  In Exchange, select **All assets** and search for `Apache Kafka`.

5.  Select the connector and click **Add to project**.

6.  Follow the prompts to add the connector to the Mule project.

## Consumer Configuration

You can create a consumer configuration global element to reference from Apache Kafka Connector.
This enables you to apply configuration details to multiple local elements in the flow.

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Consumer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

    <table><colgroup><col> <col> <col></colgroup><thead><tr><th>Connection Type</th><th>Field Name</th><th>Description</th></tr></thead><tbody><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka consumer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the consumer can use to connect to the Kafka cluster</p></td></tr><tr><td></td><td><p>Group ID</p></td><td><p>Default group ID for all the Kafka consumers that use this configuration</p></td></tr><tr><td><p>Consumer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kafka configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Consumer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Consumer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Consumer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Consumer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Producer Configuration

Create a producer configuration global element:

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Producer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

<table><colgroup><col> <col> <col></colgroup><tbody><tr><td><p>Connection Type</p></td><td><p>Field Name</p></td><td><p>Description</p></td></tr><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka producer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the producer can use to connect to the Kafka cluster</p></td></tr><tr><td><p>Producer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kerberos configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Producer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Producer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Producer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafa</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Producer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Configure TLS

To enable TLS for your app:

1.  Click the **TLS** tab to configure the truststore and keystore:

    - **Trust Store Configuration**

      - Path  
        Location of the truststore file.

      - Password  
        Password for the truststore file.

      - Type  
        File format of the truststore file.

      - Algorithm  
        Algorithm the truststore uses.

      - Insecure  
        Boolean that determines whether or not to validate the truststore. If set to `true`, no
        validation occurs. The default value is `false`.

    - **Key Store Configuration**

      - Type  
        Optionally specify the file format of the keystore file. The default value is `JKS`.

      - Path  
        Location of the keystore file. This is optional and can be used for two-way authentication
        for the connector.

      - Alias  
        Attribute that indicates the alias of the key to use when the keystore contains many private
        keys. If not defined, the first key in the file is used by default.

      - Key password  
        Key manager password, which is the password for the private key inside the keystore.

      - Password  
        Store password for the keystore file. This is optional and needed only if the **Key Store
        Location** is configured.

      - Algorithm  
        Algorithm used in the keystore.

        ![Kafka consumer configuration window](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-tls-studio-config.png)

## Configure the Commit Operation

1.  Drag the **Commit** operation to the Studio canvas.

2.  Configure the **Commit** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><tbody><tr><td><p>Name</p></td><td><p>Type</p></td><td><p>Description</p></td><td><p>Default Value</p></td><td><p>Required</p></td></tr><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>The name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Consumer commit key</p></td><td><div><div><p>String</p></div></div></td><td><p>The commitKey of the last poll. This operation is valid only when used inside a flow that is using one of the listener sources (<strong>Batch message listener</strong> or <strong>Message listener</strong>) which inserts this value as an attribute in the Mule event.</p></td><td></td><td><p>x</p></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-commit-studio-config-general.png)

3.  In the **Advanced** tab, configure the reconnection strategy.

## Configure the Consume Operation

1.  Drag the **Consume** operation to the Studio canvas.

2.  Configure the **Consume** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>The unit of time for the timeout property.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-consume-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configure to use repeatable streams.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression that evaluates the operation’s output. The outcome of the evaluation is stored in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Publish Operation

1.  Drag the **Publish** operation to the Studio canvas.

2.  Configure the **Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) The topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for producer config](/mulesoft/current/en-us/kafka-connector/4.12/_images/kafka-publish-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Bulk Publish Operation

1.  Drag the **Bulk Publish** operation to the Studio canvas.

2.  Configure the **Bulk Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of KafkaMessage</p></div></div></td><td><div><div><p>The list of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

For an example that builds the required `KafkaMessage` array and publishes multiple messages, see
[Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.12/kafka-connector-bulk-publish-example).

## Configure the Seek Operation

1.  Drag the **Seek** operation to the Studio canvas.

2.  Configure the **Seek** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which to perform the seek operation.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number for which to modify the offset.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure an Input Source

Configure an input source for the connector, such as the **Message Consumer** operation:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>Name of the topic from which to consume messages.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether to execute this source on only the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div><div><p>Configure to use repeatable streams.</p></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

You can also use the **Batch Message Listener** operation as an input source in Apache Kafka
Connector:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Connector Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>The amount of time to block.</p></div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>The time unit for the polling timeout. This combines with poll timeout to define the total timeout for the polling.</p></div></div></td></tr><tr><td><p><strong>Acknowledgment mode</strong></p></td><td><div><div><p>Declares the supported acknowledgment mode type.</p></div></div></td></tr><tr><td><p><strong>Amount of parallel consumers</strong></p></td><td><div><div><p>Declares how many consumers to use in parallel.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether this source should be executed only on the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><p>Define the streaming strategy.</p></div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=a4f228e637524ad10063bebaa90c7dd20e0865619ab756d2a4867295e95f2039 url=/mulesoft/current/en-us/kafka-connector/4.13/kafka-connector-studio.md -->

---
product: Apache Kafka Connector
version: 4.13
---

# Using Anypoint Studio to Configure Apache Kafka 4.13

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In Anypoint Studio, add Anypoint Connector for Apache Kafka (Apache Kafka Connector) to a Mule
project, configure the connection to the Kafka cluster, and configure an input source for the
connector.

To configure a connector in Anypoint Studio:

1.  Add the connector to a Mule project.

2.  Configure the connector.

3.  Configure an input source for the connector.

## Add the Connector in Studio

1.  In Studio, create a Mule Project.

2.  In the Mule Palette, click **(X) Search in Exchange**.

3.  In **Add Modules to Project**, type the name of the connector in the search field.

4.  Click the connector name in **Available modules**.

5.  Click **Add**.

6.  Click **Finish**.

## Add the Connector Using Exchange

1.  In Studio, create a Mule Project.

2.  Click the Exchange **(X)** icon in the upper-left of the Studio task bar.

3.  In Exchange, click **Login** and supply your Anypoint Platform username and password.

4.  In Exchange, select **All assets** and search for `Apache Kafka`.

5.  Select the connector and click **Add to project**.

6.  Follow the prompts to add the connector to the Mule project.

## Consumer Configuration

You can create a consumer configuration global element to reference from Apache Kafka Connector.
This enables you to apply configuration details to multiple local elements in the flow.

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Consumer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

    <table><colgroup><col> <col> <col></colgroup><thead><tr><th>Connection Type</th><th>Field Name</th><th>Description</th></tr></thead><tbody><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka consumer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the consumer can use to connect to the Kafka cluster</p></td></tr><tr><td></td><td><p>Group ID</p></td><td><p>Default group ID for all the Kafka consumers that use this configuration</p></td></tr><tr><td><p>Consumer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kafka configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Consumer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Consumer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Consumer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Consumer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Producer Configuration

Create a producer configuration global element:

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Producer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

<table><colgroup><col> <col> <col></colgroup><tbody><tr><td><p>Connection Type</p></td><td><p>Field Name</p></td><td><p>Description</p></td></tr><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka producer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the producer can use to connect to the Kafka cluster</p></td></tr><tr><td><p>Producer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kerberos configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Producer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Producer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Producer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafa</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Producer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Configure TLS

To enable TLS for your app:

1.  Click the **TLS** tab to configure the truststore and keystore:

    - **Trust Store Configuration**

      - Path  
        Location of the truststore file.

      - Password  
        Password for the truststore file.

      - Type  
        File format of the truststore file.

      - Algorithm  
        Algorithm the truststore uses.

      - Insecure  
        Boolean that determines whether or not to validate the truststore. If set to `true`, no
        validation occurs. The default value is `false`.

    - **Key Store Configuration**

      - Type  
        Optionally specify the file format of the keystore file. The default value is `JKS`.

      - Path  
        Location of the keystore file. This is optional and can be used for two-way authentication
        for the connector.

      - Alias  
        Attribute that indicates the alias of the key to use when the keystore contains many private
        keys. If not defined, the first key in the file is used by default.

      - Key password  
        Key manager password, which is the password for the private key inside the keystore.

      - Password  
        Store password for the keystore file. This is optional and needed only if the **Key Store
        Location** is configured.

      - Algorithm  
        Algorithm used in the keystore.

        ![Kafka consumer configuration window](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-tls-studio-config.png)

## Configure the Commit Operation

1.  Drag the **Commit** operation to the Studio canvas.

2.  Configure the **Commit** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><tbody><tr><td><p>Name</p></td><td><p>Type</p></td><td><p>Description</p></td><td><p>Default Value</p></td><td><p>Required</p></td></tr><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>The name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Consumer commit key</p></td><td><div><div><p>String</p></div></div></td><td><p>The commitKey of the last poll. This operation is valid only when used inside a flow that is using one of the listener sources (<strong>Batch message listener</strong> or <strong>Message listener</strong>) which inserts this value as an attribute in the Mule event.</p></td><td></td><td><p>x</p></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-commit-studio-config-general.png)

3.  In the **Advanced** tab, configure the reconnection strategy.

## Configure the Consume Operation

1.  Drag the **Consume** operation to the Studio canvas.

2.  Configure the **Consume** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>The unit of time for the timeout property.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-consume-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configure to use repeatable streams.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression that evaluates the operation’s output. The outcome of the evaluation is stored in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Publish Operation

1.  Drag the **Publish** operation to the Studio canvas.

2.  Configure the **Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) The topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for producer config](/mulesoft/current/en-us/kafka-connector/4.13/_images/kafka-publish-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Bulk Publish Operation

1.  Drag the **Bulk Publish** operation to the Studio canvas.

2.  Configure the **Bulk Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of KafkaMessage</p></div></div></td><td><div><div><p>The list of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

For an example that builds the required `KafkaMessage` array and publishes multiple messages, see
[Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.13/kafka-connector-bulk-publish-example).

## Configure the Seek Operation

1.  Drag the **Seek** operation to the Studio canvas.

2.  Configure the **Seek** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which to perform the seek operation.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number for which to modify the offset.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure an Input Source

Configure an input source for the connector, such as the **Message Consumer** operation:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>Name of the topic from which to consume messages.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether to execute this source on only the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div><div><p>Configure to use repeatable streams.</p></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

You can also use the **Batch Message Listener** operation as an input source in Apache Kafka
Connector:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Connector Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>The amount of time to block.</p></div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>The time unit for the polling timeout. This combines with poll timeout to define the total timeout for the polling.</p></div></div></td></tr><tr><td><p><strong>Acknowledgment mode</strong></p></td><td><div><div><p>Declares the supported acknowledgment mode type.</p></div></div></td></tr><tr><td><p><strong>Amount of parallel consumers</strong></p></td><td><div><div><p>Declares how many consumers to use in parallel.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether this source should be executed only on the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><p>Define the streaming strategy.</p></div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=ac8ca0a97ce17d3b87765c26114e068f99f101b7ea9c86db59101e98ee34e4de url=/mulesoft/current/en-us/kafka-connector/4.14/kafka-connector-studio.md -->

---
product: Apache Kafka Connector
version: 4.14
---

# Using Anypoint Studio to Configure Apache Kafka 4.14

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In Anypoint Studio, add Anypoint Connector for Apache Kafka (Apache Kafka Connector) to a Mule
project, configure the connection to the Kafka cluster, and configure an input source for the
connector.

To configure a connector in Anypoint Studio:

1.  Add the connector to a Mule project.

2.  Configure the connector.

3.  Configure an input source for the connector.

## Add the Connector in Studio

1.  In Studio, create a Mule Project.

2.  In the Mule Palette, click **(X) Search in Exchange**.

3.  In **Add Modules to Project**, type the name of the connector in the search field.

4.  Click the connector name in **Available modules**.

5.  Click **Add**.

6.  Click **Finish**.

## Add the Connector Using Exchange

1.  In Studio, create a Mule Project.

2.  Click the Exchange **(X)** icon in the upper-left of the Studio task bar.

3.  In Exchange, click **Login** and supply your Anypoint Platform username and password.

4.  In Exchange, select **All assets** and search for `Apache Kafka`.

5.  Select the connector and click **Add to project**.

6.  Follow the prompts to add the connector to the Mule project.

## Consumer Configuration

You can create a consumer configuration global element to reference from Apache Kafka Connector.
This enables you to apply configuration details to multiple local elements in the flow.

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Consumer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

    <table><colgroup><col> <col> <col></colgroup><thead><tr><th>Connection Type</th><th>Field Name</th><th>Description</th></tr></thead><tbody><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka consumer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the consumer can use to connect to the Kafka cluster</p></td></tr><tr><td></td><td><p>Group ID</p></td><td><p>Default group ID for all the Kafka consumers that use this configuration</p></td></tr><tr><td><p>Consumer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kafka configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Consumer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Consumer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Consumer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Consumer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Producer Configuration

Create a producer configuration global element:

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Producer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

<table><colgroup><col> <col> <col></colgroup><tbody><tr><td><p>Connection Type</p></td><td><p>Field Name</p></td><td><p>Description</p></td></tr><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka producer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the producer can use to connect to the Kafka cluster</p></td></tr><tr><td><p>Producer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kerberos configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Producer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Producer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Producer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafa</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Producer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Configure TLS

To enable TLS for your app:

1.  Click the **TLS** tab to configure the truststore and keystore:

    - **Trust Store Configuration**

      - Path  
        Location of the truststore file.

      - Password  
        Password for the truststore file.

      - Type  
        File format of the truststore file.

      - Algorithm  
        Algorithm the truststore uses.

      - Insecure  
        Boolean that determines whether or not to validate the truststore. If set to `true`, no
        validation occurs. The default value is `false`.

    - **Key Store Configuration**

      - Type  
        Optionally specify the file format of the keystore file. The default value is `JKS`.

      - Path  
        Location of the keystore file. This is optional and can be used for two-way authentication
        for the connector.

      - Alias  
        Attribute that indicates the alias of the key to use when the keystore contains many private
        keys. If not defined, the first key in the file is used by default.

      - Key password  
        Key manager password, which is the password for the private key inside the keystore.

      - Password  
        Store password for the keystore file. This is optional and needed only if the **Key Store
        Location** is configured.

      - Algorithm  
        Algorithm used in the keystore.

        ![Kafka consumer configuration window](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-tls-studio-config.png)

## Configure the Commit Operation

1.  Drag the **Commit** operation to the Studio canvas.

2.  Configure the **Commit** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><tbody><tr><td><p>Name</p></td><td><p>Type</p></td><td><p>Description</p></td><td><p>Default Value</p></td><td><p>Required</p></td></tr><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>The name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Consumer commit key</p></td><td><div><div><p>String</p></div></div></td><td><p>The commitKey of the last poll. This operation is valid only when used inside a flow that is using one of the listener sources (<strong>Batch message listener</strong> or <strong>Message listener</strong>) which inserts this value as an attribute in the Mule event.</p></td><td></td><td><p>x</p></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-commit-studio-config-general.png)

3.  In the **Advanced** tab, configure the reconnection strategy.

## Configure the Consume Operation

1.  Drag the **Consume** operation to the Studio canvas.

2.  Configure the **Consume** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>The unit of time for the timeout property.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-consume-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configure to use repeatable streams.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression that evaluates the operation’s output. The outcome of the evaluation is stored in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Publish Operation

1.  Drag the **Publish** operation to the Studio canvas.

2.  Configure the **Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) The topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for producer config](/mulesoft/current/en-us/kafka-connector/4.14/_images/kafka-publish-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Bulk Publish Operation

1.  Drag the **Bulk Publish** operation to the Studio canvas.

2.  Configure the **Bulk Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of KafkaMessage</p></div></div></td><td><div><div><p>The list of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

For an example that builds the required `KafkaMessage` array and publishes multiple messages, see
[Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/4.14/kafka-connector-bulk-publish-example).

## Configure the Seek Operation

1.  Drag the **Seek** operation to the Studio canvas.

2.  Configure the **Seek** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which to perform the seek operation.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number for which to modify the offset.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure an Input Source

Configure an input source for the connector, such as the **Message Consumer** operation:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>Name of the topic from which to consume messages.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether to execute this source on only the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div><div><p>Configure to use repeatable streams.</p></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

You can also use the **Batch Message Listener** operation as an input source in Apache Kafka
Connector:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Connector Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>The amount of time to block.</p></div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>The time unit for the polling timeout. This combines with poll timeout to define the total timeout for the polling.</p></div></div></td></tr><tr><td><p><strong>Acknowledgment mode</strong></p></td><td><div><div><p>Declares the supported acknowledgment mode type.</p></div></div></td></tr><tr><td><p><strong>Amount of parallel consumers</strong></p></td><td><div><div><p>Declares how many consumers to use in parallel.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether this source should be executed only on the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><p>Define the streaming strategy.</p></div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)

<!-- document id=126e8aca4c7a9f3607cd49d800d5788557033a82860c532ba0fbc13958398b8a url=/mulesoft/current/en-us/kafka-connector/latest/kafka-connector-studio.md -->

---
product: Apache Kafka Connector
version: 4.15
is-latest-version: true
---

# Using Anypoint Studio to Configure Apache Kafka 4.15

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In Anypoint Studio, add Anypoint Connector for Apache Kafka (Apache Kafka Connector) to a Mule
project, configure the connection to the Kafka cluster, and configure an input source for the
connector.

To configure a connector in Anypoint Studio:

1.  Add the connector to a Mule project.

2.  Configure the connector.

3.  Configure an input source for the connector.

## Add the Connector in Studio

1.  In Studio, create a Mule Project.

2.  In the Mule Palette, click **(X) Search in Exchange**.

3.  In **Add Modules to Project**, type the name of the connector in the search field.

4.  Click the connector name in **Available modules**.

5.  Click **Add**.

6.  Click **Finish**.

## Add the Connector Using Exchange

1.  In Studio, create a Mule Project.

2.  Click the Exchange **(X)** icon in the upper-left of the Studio task bar.

3.  In Exchange, click **Login** and supply your Anypoint Platform username and password.

4.  In Exchange, select **All assets** and search for `Apache Kafka`.

5.  Select the connector and click **Add to project**.

6.  Follow the prompts to add the connector to the Mule project.

## Consumer Configuration

You can create a consumer configuration global element to reference from Apache Kafka Connector.
This enables you to apply configuration details to multiple local elements in the flow.

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Consumer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

    <table><colgroup><col> <col> <col></colgroup><thead><tr><th>Connection Type</th><th>Field Name</th><th>Description</th></tr></thead><tbody><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka consumer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the consumer can use to connect to the Kafka cluster</p></td></tr><tr><td></td><td><p>Group ID</p></td><td><p>Default group ID for all the Kafka consumers that use this configuration</p></td></tr><tr><td><p>Consumer SASL/AWS IAM</p></td><td><p>AWS Region</p></td><td><p>AWS Region where the Amazon MSK cluster is located</p></td></tr><tr><td><p>Consumer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kafka configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Consumer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Consumer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Consumer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Consumer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Producer Configuration

Create a producer configuration global element:

1.  On the Studio canvas, click **Global Elements**.

2.  Click **Create** and expand **Connector Configuration**.

3.  Select **Apache Kafka Producer configuration** and click **OK**.

4.  In the **Connection** field, select a connection type.

5.  Enter values for the following fields:

<table><colgroup><col> <col> <col></colgroup><tbody><tr><td><p>Connection Type</p></td><td><p>Field Name</p></td><td><p>Description</p></td></tr><tr><td><p>All connection types</p></td><td><p>Bootstrap Server URLs</p></td><td><p>List of host-port pairs that establish the initial connection to the Kafka cluster. Set this value to the <code>bootstrap.servers</code> value you must provide to Kafka producer clients.</p></td></tr><tr><td></td><td><p>Bean reference</p></td><td><p>URLs that the producer can use to connect to the Kafka cluster</p></td></tr><tr><td><p>Producer SASL/AWS IAM</p></td><td><p>AWS Region</p></td><td><p>AWS Region where the Amazon MSK cluster is located</p></td></tr><tr><td><p>Producer Kerberos</p></td><td><p>Principal</p></td><td><p>Entity for the Apache Kafka system to authenticate</p></td></tr><tr><td></td><td><p>Service name</p></td><td><p>Kerberos principal name associated with Kafka Connector</p></td></tr><tr><td></td><td><p>Kerberos configuration file (krb5.conf)</p></td><td><p>File that contains Kerberos configuration information</p></td></tr><tr><td><p>Producer SASL/OAUTHBEARER</p></td><td><p>Client ID</p></td><td><p>Unique identifier assigned to the OAuth client, facilitating secure authentication and authorization processes</p></td></tr><tr><td></td><td><p>Client Secret</p></td><td><p>Confidential authentication credential assigned to the OAuth client</p></td></tr><tr><td></td><td><p>OAuth Token Endpoint</p></td><td><p>URL where clients can request access tokens from the authentication server</p></td></tr><tr><td><p>Producer SASL/SCRAM</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr><tr><td><p>Producer SASL/PLAIN</p></td><td><p>Username</p></td><td><p>Username with which to log in to Kafa</p></td></tr><tr><td></td><td><p>Password</p></td><td><p>Password with which to log in to Kafka</p></td></tr><tr><td><p>Producer SASL/TOKEN</p></td><td><p>Token ID</p></td><td><p>ID of the token</p></td></tr><tr><td></td><td><p>Token HMAC</p></td><td><p>Token HMAC</p></td></tr><tr><td></td><td><p>Encryption type</p></td><td><p>Encryption algorithm used by SCRAM</p></td></tr></tbody></table>

## Configure TLS

To enable TLS for your app:

1.  Click the **TLS** tab to configure the truststore and keystore:

    - **Trust Store Configuration**

      - Path  
        Location of the truststore file.

      - Password  
        Password for the truststore file.

      - Type  
        File format of the truststore file.

      - Algorithm  
        Algorithm the truststore uses.

      - Insecure  
        Boolean that determines whether or not to validate the truststore. If set to `true`, no
        validation occurs. The default value is `false`.

    - **Key Store Configuration**

      - Type  
        Optionally specify the file format of the keystore file. The default value is `JKS`.

      - Path  
        Location of the keystore file. This is optional and can be used for two-way authentication
        for the connector.

      - Alias  
        Attribute that indicates the alias of the key to use when the keystore contains many private
        keys. If not defined, the first key in the file is used by default.

      - Key password  
        Key manager password, which is the password for the private key inside the keystore.

      - Password  
        Store password for the keystore file. This is optional and needed only if the **Key Store
        Location** is configured.

      - Algorithm  
        Algorithm used in the keystore.

        ![Kafka consumer configuration window](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-tls-studio-config.png)

## Configure the Commit Operation

1.  Drag the **Commit** operation to the Studio canvas.

2.  Configure the **Commit** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><tbody><tr><td><p>Name</p></td><td><p>Type</p></td><td><p>Description</p></td><td><p>Default Value</p></td><td><p>Required</p></td></tr><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>The name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Consumer commit key</p></td><td><div><div><p>String</p></div></div></td><td><p>The commitKey of the last poll. This operation is valid only when used inside a flow that is using one of the listener sources (<strong>Batch message listener</strong> or <strong>Message listener</strong>) which inserts this value as an attribute in the Mule event.</p></td><td></td><td><p>x</p></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-commit-studio-config-general.png)

3.  In the **Advanced** tab, configure the reconnection strategy.

## Configure the Consume Operation

1.  Drag the **Consume** operation to the Studio canvas.

2.  Configure the **Consume** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Consumption timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>The number of time units that this operation waits for receiving messages.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Timeout time unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div><div><p>The unit of time for the timeout property.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for consumer config](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-consume-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><div><div><p>Configure to use repeatable streams.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable that stores the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression that evaluates the operation’s output. The outcome of the evaluation is stored in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Publish Operation

1.  Drag the **Publish** operation to the Studio canvas.

2.  Configure the **Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The topic to publish to.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>(Optional) The topic partition.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Key</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Key for the published message.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Message</strong></p></td><td><div><div><p>Binary</p></div></div></td><td><div><div><p>(Optional) Message content of the message.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Headers</strong></p></td><td><div><div><p>Object</p></div></div></td><td><div><div><p>(Optional) Headers for the message.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

    ![Kafka config panel in General tab for producer config](/mulesoft/current/en-us/kafka-connector/latest/_images/kafka-publish-studio-config.png)

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure the Bulk Publish Operation

1.  Drag the **Bulk Publish** operation to the Studio canvas.

2.  Configure the **Bulk Publish** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Messages</strong></p></td><td><div><div><p>Array of KafkaMessage</p></div></div></td><td><div><div><p>The list of messages to publish.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Transactional Action</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>ALWAYS_JOIN</p></li><li><p>JOIN_IF_POSSIBLE</p></li><li><p>NOT_SUPPORTED</p></li></ul></div></div></td><td><div><div><p>The type of joining action that operations can take regarding transactions.</p></div></div></td><td><div><div><p><code>JOIN_IF_POSSIBLE</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Variable</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>The name of a variable to store the operation’s output.</p></div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Target Value</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>An expression to evaluate against the operation’s output and store the expression outcome in the target variable.</p></div></div></td><td><div><div><p><code>#[payload]</code></p></div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

For an example that builds the required `KafkaMessage` array and publishes multiple messages, see
[Publish Multiple Messages with Bulk Publish](https://docs.mulesoft.com/kafka-connector/latest/kafka-connector-bulk-publish-example).

## Configure the Seek Operation

1.  Drag the **Seek** operation to the Studio canvas.

2.  Configure the **Seek** operation in the **General** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the configuration to use.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Name of the topic on which to perform the seek operation.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Partition</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Partition number for which to modify the offset.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr><tr><td><p><strong>Offset</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Offset value to commit for the configured partition.</p></div></div></td><td><div></div></td><td><div><div><p>x</p></div></div></td></tr></tbody></table>

3.  Configure the following settings in the **Advanced** tab:

    <table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p><strong>Operation Timeout</strong></p></td><td><div><div><p>Number</p></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Operation Timeout Time Unit</strong></p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><div></div></td><td><div></div></td><td><div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div></div></td><td><div></div></td><td><div></div></td></tr></tbody></table>

## Configure an Input Source

Configure an input source for the connector, such as the **Message Consumer** operation:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Topic</strong></p></td><td><div><div><p>Name of the topic from which to consume messages.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether to execute this source on only the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div><div><p>Configure to use repeatable streams.</p></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

You can also use the **Batch Message Listener** operation as an input source in Apache Kafka
Connector:

<table><colgroup><col> <col></colgroup><thead><tr><th>Name</th><th>Description</th></tr></thead><tbody><tr><td><p><strong>Connector Configuration</strong></p></td><td><div><div><p>The name of the configuration to use.</p></div></div></td></tr><tr><td><p><strong>Poll timeout</strong></p></td><td><div><div><p>The amount of time to block.</p></div></div></td></tr><tr><td><p><strong>Poll timeout time unit</strong></p></td><td><div><div><p>The time unit for the polling timeout. This combines with poll timeout to define the total timeout for the polling.</p></div></div></td></tr><tr><td><p><strong>Acknowledgment mode</strong></p></td><td><div><div><p>Declares the supported acknowledgment mode type.</p></div></div></td></tr><tr><td><p><strong>Amount of parallel consumers</strong></p></td><td><div><div><p>Declares how many consumers to use in parallel.</p></div></div></td></tr><tr><td><p><strong>Primary Node Only</strong></p></td><td><div><div><p>Whether this source should be executed only on the primary node when running in a cluster.</p></div></div></td></tr><tr><td><p><strong>Streaming Strategy</strong></p></td><td><div><div><p>Define the streaming strategy.</p></div><div><ul><li><p>repeatable-in-memory-stream</p></li><li><p>repeatable-file-store-stream</p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td></tr><tr><td><p><strong>Redelivery Policy</strong></p></td><td><div><div><p>Defines a policy for processing the redelivery of the same message.</p></div></div></td></tr><tr><td><p><strong>Reconnection Strategy</strong></p></td><td><div><div><p>A retry strategy in case of connectivity errors.</p></div><div><ul><li><p>reconnect</p></li><li><p>reconnect-forever</p></li></ul></div></div></td></tr></tbody></table>

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)