-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Language bindings development
librdkafka's string-based key=value configuration property interface controls most runtime behaviour and evolves over time. Most features are also only configuration-based, meaning they do not require a new API (SSL and SASL are two good examples which are purely enabled through configuration properties) and thus no changes needed to the binding/application code.
If your language binding/applications allows configuration properties to be set in a pass-through fashion without any pre-checking done by your binding code it means that a simple upgrade of the underlying librdkafka library (but not your bindings) will provide new features to the user.
The error constants, both the official (value >= 0) errors as well as the internal (value < 0) evolve constantly.
To avoid hard-coding them to expose to your users, librdkafka now provides an API to extract the full list programmatically during runtime, see rd_kafka_get_err_descs().
KIP-511 introduces a means for a Kafka client to report its implementation name and version to the broker, the broker then exposes this as metrics (e.g., through JMX) to help Kafka operators troubleshoot problematic clients, understand the impact of broker and client upgrades, etc. This requires broker version 2.4.0 or later (metrics added in 2.5.0).
librdkafka will send its name (librdkafka) and version (e.g., v1.3.0) upon connect to a supporting broker.
To help distinguish high-level client bindings on top of librdkafka, a client binding should configure the following two properties:
-
client.software.name- set to the binding name, e.g,confluent-kafka-goornode-rdkafka. -
client.software.version- the version of the binding and the version of librdkafka, e.g.,v1.3.0-librdkafka-v1.3.0or1.2.0-librdkafka-v1.3.0. It is highly recommended to include the librdkafka version in this version string.
These configuration properties are hidden (from CONFIGURATION.md et.al.) as they should typically not be modified by the user.
You are free to reuse the librdkafka API and CONFIGURATION documentation in your project, but please do return any documentation improvements back to librdkafka (file a github pull request).
You are welcome to direct your users to librdkafka's Gitter chat room as long as you monitor the conversions in there to pick up questions specific to your bindings. But for the most part user questions are usually generic enough to apply to all librdkafka bindings.