Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve documentation for callbackPollMode #175

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

kamek-pf
Copy link

I lost a few hours to this, so I figured the extra comment might be useful to someone else.
For the record, I was setting up my consumer props like this:

let brokers = brokersList $ map BrokerAddress $ (kafkaBrokers . kafkaConfig) context
    group = groupId $ ConsumerGroupId $ (kafkaGroup . kafkaConfig) context
    logs = logLevel KafkaLogInfo
    commit = autoCommit $ Millis 5000
    pollMode = callbackPollMode CallbackPollModeSync
 in brokers <> group <> pollMode <> commit <> logs

which caused the callbackPollMode to be reset to CallbackPollModeAsync (the default).

For this to work the last line should be brokers <> group <> commit <> logs <> pollMode.

@kamek-pf
Copy link
Author

kamek-pf commented Apr 21, 2021

Semi related, and I have no idea how other rdkafka bindings behave, but CallbackPollModeAsync is a surprising default to me.
If your processing pipeline can't keep up with the async thread polling Kafka in the background, messages will accumulate in memory and then you lose the main form of backpressure.

Not a huge deal if you're aware of the implications, but I've been using this library for a few months and this definitely went over my head until I started digging into strange memory usage patterns of some services we have.

@robinp
Copy link

robinp commented Sep 26, 2021

I'm not very familiar with the rd-variant of Kafka either, but a few cents so far:

  • Based on the top of https://docs.confluent.io/2.0.0/clients/librdkafka/rdkafka_8h.html, rd_kafka_consume_batch_queue, which the async mode uses, is part of the legacy simple consumer API. While the subscribe / consumer_poll API used by the sync mode is part of the new high-level API. It seems very strange to mix the two in the lib. For example, I don't see why the async mode even works, as it uses a queue, but rd_kafka_consume_start_queue is never called (which according the docs should be).

  • The new, high-level API will anyway do async fetches it the background (see queued.min.messages and queued.max.messages.kbytes in https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md), and poll really just fetches from the local queue. So the async / batch mode could be ditched, and the functionality, if needed, implemented on top of the single-message poll from the local queue.

But as I said, kind of new to rd_kafka, correct if I'm missing something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants