Deprecations and default-changes in v1.x

[edenhill]

librdkafka v1.0 will be API and ABI compatible with the 0.x release train, but will deprecate a number of legacy APIs and configuration settings that will be removed in v2.0.

APIs and functionality to deprecate:

• File-based offset storage -> simplies the offset management code
• Legacy consumer API: rd_kafka_consume_start|stop() -> simplifies internal consumer handling
• rd_kafka_conf_set_default_topic_config() -> global config fallthru covers this functionality
• rd_kafka_conf_set_dr_cb() -> rd_kafka_conf_set_dr_msg_cb() is future proof
• rd_kafka_metadata() -> will be modified in v2.0 to a more generic and future proof interface
• rd_kafka_set_log_cb|rd_kafka_set_log_level() -> use configuration interface
• rd_kafka_AlterConfigs() -> rd_kafka_ModifyConfigs() with proper atomic functionality

Configuration settings to deprecate:

• socket.blocking.max.ms -> no longer needed (on Sparse/on-demand connections #2019 merge)
• topic.metadata.refresh.fast.cnt -> no longer needed
• produce.offset.report -> no longer needed
• max.in.flight.per.connection -> will remain, but max.in.flight.per.partition will be added and max.in.flight will be aliased to it.
• offset.store.path|sync.interval.ms|method -> only broker commits will be supported
• reconnect.backoff.jitter.ms -> no longer used, replaced by reconnect.backoff.ms and reconnect.backoff.max.ms.

Other changes:

• Enforcement of compatible configuration
• The experimental LIFO queuing strategy (queuing.strategy=lifo) will be removed, and rd_kafka_conf_set_msg_order_cmp() with it. Selective ordering complicates the internal ordering guarantees for idempotent producer.

Default changes:

• acks -> will be set to all, was 1.
• broker.version.fallback -> will be set to an ApiVersionRequest supporting version
• enable.sparse.connections -> will be set to true
• enable.partition.eof -> will be set to false

Open questions:

• Can we remove the deprecated string-based configuration properties without breaking the API stability guarantee? -> Probably no, it will break existing applications.

Feedback welcome.