sendToKafka
Processor that acts as a Kafka producer to publish key-value pairs to a given Kafka server.
Properties
Name | Summary |
---|---|
|
Required list of host/port pairs to use for establishing the initial connection to the Kafka cluster. This string must be in the form of |
|
Name of the topic to which the message should be published. Required. |
|
Number of acknowledgments the producer requires the leader to have received before considering a request complete. Available options are defined on the |
|
The upper bound on the time to report success or failure after a call to |
|
The upper bound on the time to get metadata from the broker. Used to verify connection to the server, as well as obtain information about the cluster. This value should be kept considerably low, since it controls how fast a connection attempt will fail when the backend has problems. Optional and defaults to the value from the flow server config. |
|
The maximum amount of time (in milliseconds) the client will wait for the response of a request. Optional and defaults to the value from the flow server config. |
|
Specifies how long the producer will wait for messages before sending them to the broker. It is used to batch several messages together in a single request, reducing traffic to the broker. Messages will be sent once either the |
|
Upper bound on the batch size in bytes. If there is a linger period, the producer will try to put several messages in a single batch until a |
|
The |
|
Optional, maximum number of unacknowledged requests the client will send on a single connection before blocking. The client usually creates one connection per broker in the cluster. The recommended strategy for this parameter is to use no less than half of the potential requests per broker in the cluster. This can be determined with the following equations:
For example, when the Kafka producer receives 2000 messages of about 600 bytes each, has a batch size of 16000 bytes, and must deliver it to a cluster of 12 brokers, the following math applies:
When the Kafka producer receives 2 messages of about 8000000 bytes each, has a batch size of 16000 bytes, and must deliver it to a cluster of 3 brokers, the following math applies:
When the Kafka producer receives 2000 messages of about 600 bytes each, has a batch size of 16000 bytes, and must deliver it to a cluster of 1 broker, the following math applies:
|
|
Key used to look up the credentials needed to connect to the Kafka broker. Optional and uses no authentication by default. |
|
Optional, descriptive name for the processor. |
|
Required identifier of the processor, unique across all processors within the flow. Must be between 3 and 30 characters long; contain only lower and uppercase alphabetical characters (a-z and A-Z), numbers, dashes ("-"), and underscores ("_"); and start with an alphabetical character. In other words, it adheres to the regex pattern |
|
Optional set of custom properties in a simple jdk-format, that are added to the message exchange properties before processing the incoming payload. Any existing properties with the same name will be replaced by properties defined here. |
|
Whether the incoming payload is available for error processing on failure. Defaults to |
Sub-builders
Name | Summary |
---|---|
Strategy for providing message processing hints to the server. Optional. |
|
Strategy for describing the external system integration. Optional. |
|
Strategy for configuring the processor’s circuit breaker. Optional. |
|
Strategy for describing how a processor’s message is logged on the server. |
|
Strategy for archiving payloads. |
|
Strategy that customizes the conversion of an incoming payload by a processor (e.g., string to object). Should be used when the processor’s default conversion logic cannot be used. |
Details
Authentication
The authenticationConfigKey
property supports secrets of type UserNameAndPassword and Tls. You can specify multiple secrets by providing them as a comma-separated list. Comma-separated list support is designed to allow users to combine a Tls secret with a UserNameAndPassword secret. This is useful when you are using SASL-SSL/SCRAM (SHA-256) username/password authentication and also need to add a server trust store or other TLS configuration. For example:
authenticationConfigKey: "tlsSecret,usernamePasswordSecret"
The behavior is undefined if multiple secrets of the same type are provided.
We currently support only SASL-SSL/SCRAM (SHA-256) and mTLS authentication methods.
See the Secret Types documentation for formatting details.