Kafka Toolkit > com.ibm.streamsx.kafka 3.2.2 > com.ibm.streamsx.kafka > KafkaProducer
The KafkaProducer operator is used to produce messages on Kafka topics. The operator can be configured to produce messages to one or more topics.
This version of the toolkit supports Apache Kafka 0.10.2, 0.11, 1.0, 1.1, and all 2.x versions up to 2.7.
The operator implements Kafka's KafkaProducer API of the Kafka client version 2.5.1. As a result, it supports all Kafka properties that are supported by the underlying API. The producer properties for the Kafka producer 2.5 can be found in the Apache Kafka 2.5 documentation.
When you reference files within your application, which are bundled with the Streams application bundle, for example an SSL truststore or a key tab file for Kerberos authentication, you can use the {applicationDir} placeholder in the property values. Before the configs are passed to the Kafka client, the {applicationDir} placeholder is replaced by the application directory of the application. Examples how to use the placeholder are shown below.
ssl.truststore.location={applicationDir}/etc/myTruststore.jks
or
sasl.jaas.config=com.ibm.security.auth.module.Krb5LoginModule required \
debug=true \
credsType=both \
useKeytab="{applicationDir}/etc/myKeytab.keytab" \
principal="kafka-client@EXAMPLE.DOMAIN.COM";
The {applicationDir} placeholder can also be used to reference files that are configured as system properties, for example when you must specify the Kerberos client configuration, which is typically done for Linux servers system wide in /etc/krb5.conf.
In containerized environments and in cloud infrastructures, you cannot configure a system file, however. In such a scenario you want to bundle the Kerberos config file with your application and pass the file as a system property to the Java Virtual Machine using the vmArg operator parameter like this:
vmArg: "-Djava.security.krb5.conf={applicationDir}/etc/krb5.conf";
More about accessing a kerberized Kafka cluster can be found in the Kerberos chapter of the toolkit documentation.
Properties can be specified in a file or in an application configuration. If specifying properties via a file, the propertiesFile parameter can be used. If specifying properties in an application configuration, the name of the application configuration can be specified using the appConfigName parameter.
The only property that the user is required to set is the bootstrap.servers property, which points to the Kafka brokers, for example kafka-0.mydomain:9092,kafka-1.mydomain:9092,kafka-2.mydomain:9092. All other properties are optional.
The operator sets some properties by default to enable users to quickly get started with the operator. The following lists which properties the operator sets by default:
|
Property name |
Default Value |
|---|---|
|
client.id |
Generated ID in the form: P-J<JobId>-<operator name> |
|
key.serializer |
See Automatic Serialization section below |
|
value.serializer |
See Automatic Serialization section below |
|
acks |
Controls the durability of records that are sent. Adjusted to all when the guaranteeOrdering parameter is true, or when the consistentRegionPolicy parameter is Transactional in consistent region. Otherwise acks is unchanged. The value 0 (fire and forget) is not recommended. |
|
retries |
When the guaranteeOrdering parameter is true, or when the consistentRegionPolicy parameter is Transactional in consistent region, retries is adjusted to a minimum of 1. |
|
linger.ms |
100 |
|
batch.size |
32768 |
|
max.in.flight.requests.per.connection |
Limited to 5 when guaranteeOrdering parameter is true, or when consistentRegionPolicy parameter is Transactional in consistent region. 10 in all other cases when unset. |
|
enable.idempotence |
true when guaranteeOrdering parameter is true, or when in consistent region and the consistentRegionPolicy parameter is Transactional. |
|
transactional.id |
Randomly generated ID in the form: tid-<random_string> only when in consistent region and the consistentRegionPolicy parameter is set to Transactional. |
|
transaction.timeout.ms |
adjusted to a minimum of drain timeout + 120000 milliseconds, but not greater than 900000. Adjusted only when in consistent region and consistentRegionPolicy parameter is set to Transactional. |
|
metric.reporters |
added to provided reporters: com.ibm.streamsx.kafka.clients.producer.ProducerMetricsReporter |
|
metrics.sample.window.ms |
adjusted to 10000 |
|
client.dns.lookup |
use_all_dns_ips |
|
reconnect.backoff.max.ms |
10000 |
|
reconnect.backoff.ms |
250 |
|
retry.backoff.ms |
500 |
NOTE: Although properties are adjusted, users can override any of the above properties by explicitly setting the property value in either a properties file or in an application configuration. Not all properties or possible property values, which can be specified for the Kafka producer version 2.5, are supported by all Broker versions. An example for such a config is the Zstandard compression algorithm, which is supported with broker version 2.1 and above.
Users can specify Kafka properties using Streams' application configurations. Information on configuring application configurations can be found here: Creating application configuration objects to securely store data. Each property set in the application configuration will be loaded as a Kafka property. For example, to specify the bootstrap servers that the operator should connect to, an app config property named bootstrap.servers should be created.
The operator will automatically select the appropriate serializers for the key and message based on their types. The following table outlines which deserializer will be used given a particular type:
|
Serializer |
SPL Types |
|---|---|
|
org.apache.kafka.common.serialization.StringSerializer |
rstring |
|
org.apache.kafka.common.serialization.IntegerSerializer |
int32, uint32 |
|
org.apache.kafka.common.serialization.LongSerializer |
int64, uint64 |
|
org.apache.kafka.common.serialization.FloatSerializer |
float32 |
|
org.apache.kafka.common.serialization.DoubleSerializer |
float64 |
|
org.apache.kafka.common.serialization.ByteArraySerializer |
blob |
|
Custom Metric |
Description |
|---|---|
|
connection-count |
The current number of active connections. |
|
compression-rate-avg |
The average compression rate of record batches (as percentage, 100 means no compression). |
|
topic:compression-rate |
The average compression rate of record batches for a topic (as percentage, 100 means no compression). |
|
record-queue-time-avg |
The average time in ms record batches spent in the send buffer. |
|
record-queue-time-max |
The maximum time in ms record batches spent in the send buffer. |
|
record-send-rate |
The average number of records sent per second. |
|
record-retry-total |
The total number of retried record sends |
|
topic:record-send-total |
The total number of records sent for a topic. |
|
topic:record-retry-total |
The total number of retried record sends for a topic |
|
topic:record-error-total |
The total number of record sends that resulted in errors for a topic |
|
records-per-request-avg |
The average number of records per request. |
|
requests-in-flight |
The current number of in-flight requests awaiting a response. |
|
request-rate |
The number of requests sent per second |
|
request-size-avg |
The average size of requests sent. |
|
request-latency-avg |
The average request latency in ms |
|
request-latency-max |
The maximum request latency in ms |
|
batch-size-avg |
The average number of bytes sent per partition per-request. |
|
outgoing-byte-rate |
The number of outgoing bytes sent to all servers per second |
|
bufferpool-wait-time-total |
The total time an appender waits for space allocation in nanoseconds. |
|
buffer-available-bytes |
The total amount of buffer memory that is not being used (either unallocated or in the free list). |
A config checkpoint clause has no effect to the operator.
The producer operator can participate in a consistent region. The operator cannot be the start of a consistent region. When the consistent region drains, the operator flushes all accumulated outstanding records to the Kafka cluster.
The operator supports non-transactional (default behavior) and transactional message delivery. The delivery can be controlled by the consistentRegionPolicy parameter.
If the operator crashes or is reset while in a consistent region, the operator will write all tuples replayed. This ensures that every tuple sent to the operator will be written to the topic(s). However, non-transactional message delivery implies that duplicate messages may be written to the topic(s).
Messages are always inserted into a topic within the context of a transaction. Transactions are committed when the operator checkpoints. If the operator crashes or is reset while in a consistent region, the operator will abort an ongoing transaction and write all tuples replayed within a new transaction. External consumers configured with isolation.level=read_committed will not read the duplicates from the aborted transactions. Consumers that use a different isolation level will read duplicate messages as if they were produced without being part of a transaction.
For consumers that read the output topics with isolation.level=read_committed, the transactional producer minimizes number if duplicate messages with the downside that the produced messages are only visible at the checkpoint interval, which can be interpreted as additional latency.
A consumer that reads the output topics with isolation.level=read_committed can read duplicate messages when the consistent region fails after the Kafka transaction has been committed, but before the region has reached a consistent state.
NOTE 1: Transactions in Kafka have an inactivity timeout, which is configured by the producer property transaction.timeout.ms. This timeout is adjusted by the operator to a minimum of the drain timeout plus 120 seconds. The maximum value of this property is limited by the server property transaction.max.timeout.ms, which has a default value of 900000. The operator opens a transaction when the first tuple of a consistent cut is processed. Every tuple being processed resets the inactivity timer.
NOTE 2: For transactional delivery, the Kafka broker must have version 0.11 or higher. Older brokers do not support transactions.
Many exceptions thrown by the underlying Kafka API are considered fatal. In the event that Kafka throws a retriable exception, the operator behaves different when used in consistent region or not. When used in a consistent region, the operator initiates a reset of the consistent region. The reset processing will instantiate a new Kafka producer within the operator.
When the operator is not used within a consistent region, the operator tries to recover internally by instantiating a new Kafka producer within the operator and resending all producer records, which are not yet acknowledged. Records that fail two producer generations are considered being finally failed. The corresponding tuple is counted in the custom metric nFailedTuples, and, if the operator is configured with an output port, an output tuple is submitted.
In the event that Kafka throws a non-retriable exception, the tuple that caused the exception is counted in the custom metric nFailedTuples, and, if the operator is configured with an output port, an output tuple is submitted.
Some exceptions can be retried by Kafka itself, such as those that occur due to network error. Therefore, it is not recommended to set the KafkaProducer retries property to 0 to disable the producer's retry mechanism.
Optional: appConfigName, clientId, consistentRegionPolicy, flush, guaranteeOrdering, keyAttribute, krb5Debug, messageAttribute, outputErrorsOnly, partitionAttribute, propertiesFile, sslDebug, timestampAttribute, topic, topicAttribute, userLib
This port consumes tuples to be written to the Kafka topic(s). Each tuple received on this port will be written to the Kafka topic(s).
This port is an optional output port. Dependent on the outputErrorsOnly parameter, the output stream includes only tuples for input tuples that failed to get published on one or all of the specified topics, or it contains tuples corresponding to all input tuples, successfully produced ones and failed tuples.
The output port is asynchronous to the input port of the operator. The sequence of the submitted tuples may also differ from the sequence of the input tuples. Window punctuations from the input stream are not forwarded.
The schema of the output port must consist of one optional attribute of tuple type with the same schema as the input port and one optional attribute of type rstring, ustring, optional<rstring>, or optional<ustring>, that takes a JSON formatted description of the occured error, or remains empty for successfully produced tuples. Emptiness of the attribute means that the attribute contains a string with zero length when declared as rstring or ustring, and an empty optional (optional without a value) when declared as optional. Both attributes can have any names and can be declared in any order in the schema.
Example for declaring the output stream as error output:
stream <Inp failedTuple, rstring failure> Errors = KafkaProducer (Data as Inp) {
...
}
Example of the failure description, which would go into the failure attribute above:
{
"failedTopics":["topic1"],
"lastExceptionType":"org.apache.kafka.common.errors.TopicAuthorizationException",
"lastFailure":"Not authorized to access topics: [topic1]"
}
Please note that the generated JSON does not contain line breaks as in the example above, where the JSON has been broken into multiple lines to better show its structure.
Example for declaring the output stream for both successfully produced input tuples and failures:
stream <Inp inTuple, optional<rstring> failure> ProduceStatus = KafkaProducer (Data as Inp) {
param
outputErrorsOnly: false;
...
}
Optional: appConfigName, clientId, consistentRegionPolicy, flush, guaranteeOrdering, keyAttribute, krb5Debug, messageAttribute, outputErrorsOnly, partitionAttribute, propertiesFile, sslDebug, timestampAttribute, topic, topicAttribute, userLib
Specifies the name of the application configuration containing Kafka properties.
Specifies the client ID that should be used when connecting to the Kafka cluster. The value specified by this parameter will override the client.id Kafka property if specified.
Each operator must have a unique client ID. When operators are replicated by a parallel region, the channel-ID is automatically appended to the clientId to make the client-ID distinct for the parallel channels.
If this parameter is not specified and the client.id Kafka property is not specified, the operator will create an ID with the pattern C-J<job-ID>-<operator name> for a consumer operator, and P-J<job-ID>-<operator name> for a producer operator.
Specifies the policy to use when in a consistent region.
When NonTransactional is specified, the operator guarantees that every tuple is written to the topic(s) at least once. When the consistent region resets, duplicates will most likely appear in the output topic(s). For consumers of the output topics, messages appears as they are produced.
When Transactional is specified, the operator will write tuples to the topic(s) within the context of a transaction. Transactions are commited when the operator checkpoints. This implies that downstream Kafka consumers may not see the messages until operator checkpoints. Transactional delivery minimizes (though not eliminates) duplicate messages for consumers of the output topics when they are configured with the consumer property isolation.level=read_committed. Consumers that read with the default isolation level read_uncommitted see all messages as they are produced. For these consumers, there is no difference between transactional and non-transactional message delivery.
For backward compatibility, the parameter value AtLeastOnce can also be specified, but is deprecated and can be removed in a future version. AtLeastOnce is equivalent to NonTransactional.
This parameter is ignored if the operator is not part of a consistent region. The default value is NonTransactional. NOTE: Kafka brokers older than version 0.11 do not support transactions.
Specifies the number of tuples, after which the producer is flushed. When not specified, or when the parameter value is not positive, the flush interval is adaptively calculated to avoid queing times significantly over five seconds.
Flushing the producer makes all buffered records immediately available to send to the server (even if linger.ms is greater than 0) and blocks on the completion of the requests associated with the buffered records. When a small value is specified, the batching of tuples to server requests and compression (if used) may get inefficient.
Under normal circumstances, this parameter should be used only when the adaptive flush control gives not the desired results, for example when the custom metrics buffer-available-bytes goes very small and record-queue-time-max or record-queue-time-avg gets too high.
If set to true, the operator guarantees that the order of records within a topic partition is the same as the order of processed tuples when it comes to retries. This implies that the operator sets the enable.idempotence producer config automatically to true, acks to all, enables retries, and adjusts max.in.flight.requests.per.connection to an upper limit of 5.
If unset, the default value of this parameter is false, which means that the order can change due to retries as long as the producer configuration max.in.flight.requests.per.connection is greater than 1.
Note for users of Kafka 0.10.x:
The idempotent producer is not supported for Kafka versions < 0.11. When guaranteed record order is required with older Kafka servers, users must set the producer config max.in.flight.requests.per.connection=1 instead of setting guaranteeOrdering to true.
Specifies the input attribute that contains the Kafka key value. If not specified, the operator will look for an input attribute named key.
If Kerberos debugging is enabled, all Kerberos related protocol data and information is logged to the console. This setting is equivalent to vmArg: "-Dcom.ibm.security.krb5.Krb5Debug=all";. The default value for this parameter is false. The parameter is ignored when the com.ibm.security.krb5.Krb5Debug property is set via the vmArg parameter.
Specifies the attribute on the input port that contains the message payload. If not specified, the operator will look for an input attribute named message. If this parameter is not specified and there is no input attribute named message, the operator will throw an exception and terminate.
If set to true, the operator submits tuples to the optional output port only for the tuples that failed to produce. If set to false, the operator submits also tuples for the successfully produced input tuples.
If unset, the default value of this parameter is true. This parameter is ignored when the operator is not configured with an output port.
Specifies the input attribute that contains the partition number that the message should be written to. If this parameter is not specified, the operator will look for an input attribute named partition. If the user does not indicate which partition the message should be written to, then Kafka's default partitioning strategy will be used instead (partition based on the specified partitioner or in a round-robin fashion).
Specifies the name of the properties file containing Kafka properties. A relative path is always interpreted as relative to the application directory of the Streams application.
If SSL/TLS protocol debugging is enabled, all SSL protocol data and information is logged to the console. This setting is equivalent to vmArg: "-Djavax.net.debug=true";. The default value for this parameter is false. The parameter is ignored when the javax.net.debug property is set via the vmArg parameter.
Specifies the attribute on the input port that contains the timestamp for the message. If not specified, the operator will look for an input attribute named messageTimestamp. If this parameter is not specified and there is no input attribute named messageTimestamp, the operator will use the timestamp provided by Kafka (broker config log.message.timestamp.type=[CreateTime|LogAppendTime]).
Specifies the topic(s) that the producer should send messages to. The value of this parameter will take precedence over the topicAttribute parameter. This parameter will also take precedence if the input tuple schema contains an attribute named topic.
Specifies the input attribute that contains the name of the topic that the message should be written to. If this parameter is not specified, the operator will look for an input attribute named topic. This parameter value is overridden if the topic parameter is specified.
Allows the user to specify paths to JAR files that should be loaded into the operators classpath. This is useful if the user wants to be able to specify their own partitioners or assignors. The value of this parameter can either point to a specific JAR file, or to a directory. In the case of a directory, the operator will load all files ending in .jar onto the classpath. By default, this parameter will load all jar files found in <application_dir>/etc/libs.
Number of tuples that could not be produced for all topics
Number of input tuples not yet produced (acknowledged from Kafka)
Number times the input tuple processing was paused due to full tuple queue of pending tuples.
The producer generation. When a new producer is created, a new generation is created.