-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Should rd_kafka_flush always call poll? #1950
Labels
Comments
That makes sense, will fix 👍 |
👍 Thanks! |
edenhill
added a commit
that referenced
this issue
Aug 15, 2018
Could you try out the fix (on the fetcholdrktp branch)? |
edenhill
added a commit
that referenced
this issue
Aug 15, 2018
I've tested it with the python client and it works well. Thanks for the quick turnaround. Before >>> producer = confluent_kafka.Producer({'bootstrap.servers': '{}:{}'.format(kafka_host, kafka_port)})
>>> producer.produce('topic', 'data')
>>> producer.produce('topic', 'data')
>>> len(producer)
3
>>> producer.flush(0)
3L
>>> len(producer)
3 After >>> producer = confluent_kafka.Producer({'bootstrap.servers': '{}:{}'.format(kafka_host, kafka_port)})
>>> producer.produce('topic', 'data')
>>> producer.produce('topic', 'data')
>>> len(producer)
4
>>> producer.flush(0)
0
>>> len(producer)
0 |
Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
rd_kafka_flush
does not callrd_kafka_poll
if the timeout given is zero. I feel like it should always call it once since if someone is trying to use this in a non-blocking way, repeatedly callingrd_kafka_flush
with a zero timeout will not give the desired results. We can easily work around this by callingrd_kafka_poll
repeatedly and checking the queue length afterwards however I think makingrd_kafka_flush
callrd_kafka_poll
at least once would yield a nicer API to work with.How to reproduce
Produce some messages
Repeatedly call
rd_kafka_flush
Notice that the queue length does not decrease.
Checklist
Please provide the following information:
v0.10.5
0.10.2
<REPLACE with e.g., message.timeout.ms=123, auto.reset.offset=earliest, ..>
Centos 6 (x64)
debug=..
as necessary) from librdkafkaThe text was updated successfully, but these errors were encountered: