Liberty-Kafka connector options and channel properties
The liberty-kafka connector offers a range of properties to fine-tune its operation. You can set these properties on the liberty-kafka connector to define certain behaviors during operation.
You can use all these options as attributes on either the connector or a channel that uses the liberty-kafka connector. If you specify the option on both the channel and the connector, the channel takes precedence.
| Property Name | Default | Description |
|---|---|---|
topic | The name of the channel. | The Kafka topic that the channel is to either send or receive messages from. |
unacked.limit | Defaults to the value of | The number outstanding unacknowledged messages. |
fast.ack |
| Defines the acknowledge behavior of the |
context.service | If the | Enabling the concurrent feature is needed for the |
<any other property> | Uses the Kafka Client default | All other properties are passed directly as config parameters to the KafkaConsumer API. A list of required and optional properties can be found in the Kafka documentation. |
fast.ack
Properties like fast.ack allow for control over message acknowledgment processes, improving the efficiency of message processing.
In the following example, in the microprofile-config.properties file of the application, the fast.ack setting is defaulted to false for the connector, affecting all channels in the application. However, for a distinct incoming channel called foo, this setting is overridden to true. This alteration favors a quicker acknowledgment approach, which enhances the handling performance for messages that arrive on this channel.
mp.messaging.connector.liberty-kafka.fast.ack=false mp.messaging.incoming.foo.connector=liberty-kafka mp.messaging.incoming.foo.fast.ack=true
| Property Name | Default | Description |
|---|---|---|
topic | The name of the channel. | The Kafka topic that the channel is to either send or receive messages from. |
context.service | If the | Enabling the concurrent feature is needed for the |
<any other property> | Uses the Kafka Client default | All other properties are passed directly as config parameters to the KafkaProducer API. A list of required and optional properties can be found in the Kafka documentation. |
context.service
The context.service attribute specifies the Context Service for asynchronous operations, critical for performance tuning. Context Services that are defined within the application itself cannot be used with the liberty-kafka connector.
In the following example, the server.xml file defines three different context services, each with a unique identifier (rst, uvw, and xyz).
<contextService id=“rst”/> <contextService id=“uvw”/> <contextService id=“xyz”/>
The microprofile-config.properties file is part of the application’s configuration and specifies how MicroProfile features should be used within the application.
mp.messaging.connector.liberty-kafka.context.service=rst mp.messaging.incoming.def.connector=liberty-kafka mp.messaging.incoming.foo.connector=liberty-kafka mp.messaging.incoming.foo.context.service=uvw mp.messaging.outgoing.bar.connector=liberty-kafka mp.messaging.outgoing.bar.context.service=xyz
In the example, the property mp.messaging.connector.liberty-kafka.context.service=rst indicates that the Kafka connector that is used for handling messaging between services uses the rst context service by default for its operations.
The application has three channels (def, foo, and bar), which are logical endpoints for incoming and outgoing messages. The configuration for these channels specifies which Kafka connector to use (liberty-kafka) and for two of the channels (foo and bar), overrides the default context service with their own (uvw and xyz, respectively). The def channel does not specify its own context.service, so it inherits the default one (rst) defined at the connector level.
By defining separate context services, the application can isolate certain operations or configurations, which can be useful in complex applications or during integration with external systems. These configurations demonstrate the flexibility and control that you have over message processing in Open Liberty applications.
