Question: sending single message with no delay #3202
Comments
|
Can you try reproducing against master or v1.6.0-RC1? There was a recent patch that might be related. |
|
Hi, I tried v1.6.0-RC1 but am still experiencing the same problem. However, If I send a small message before this message then the message gets sent immediately. So that is the workaround that I have in place for now. Attached is the log output from v1.6.0-RC1 without sending the a message before, and then the log output without sending a message before. Thanks With sending small message first: %7|1610113305.210|INIT|rdkafka#producer-1| [thrd:app]: librdkafka v1.6.0 (0x10600ff) rdkafka#producer-1 initialized (builtin.features gzip,snappy,ssl,sasl,regex,lz4,sasl_gssapi,sasl_plain,sasl_scram,plugins,sasl_oauthbearer, CC CXX PKGCONFIG INSTALL GNULD LIBDL PLUGINS ZLIB SSL SASL_CYRUS HDRHISTOGRAM SYSLOG SNAPPY SOCKEM SASL_SCRAM SASL_OAUTHBEARER CRC32C_HW, debug 0x80) without first msg %7|1610113064.442|INIT|rdkafka#producer-1| [thrd:app]: librdkafka v1.6.0 (0x10600ff) rdkafka#producer-1 initialized (builtin.features gzip,snappy,ssl,sasl,regex,lz4,sasl_gssapi,sasl_plain,sasl_scram,plugins,sasl_oauthbearer, CC CXX PKGCONFIG INSTALL GNULD LIBDL PLUGINS ZLIB SSL SASL_CYRUS HDRHISTOGRAM SYSLOG SNAPPY SOCKEM SASL_SCRAM SASL_OAUTHBEARER CRC32C_HW, debug 0x80) |
|
Can you repro this with debug=all please? |
|
Sure, %7|1610118981.203|WAKEUPFD|rdkafka#producer-1| [thrd:app]: server1:9092/bootstrap: Enabled low-latency ops queue wake-ups |
|
Thank you. The issue is that in certain situations unknown topics are looked up once per second, and this is why you're seeing the delay here. We'll fix this after the v1.6.0 release. As a workaround you can query the topic metadata once on startup, like so: rd_kafka_topic_t *rkt = rd_kafka_topic_new(rk, "mytopic", NULL,..);
rd_kafka_metadata_t *md;
if (rd_kafka_metadata(rk, rkt, 0, rkt, &md, 10000) == RD_KAFKA_RESP_ERR_NO_ERROR)
rd_kafka_metadata_destroy(md); |
|
Great, Thanks! |
|
Hi @edenhill, just want to confirm if this was actually fixed since I'm seeing similar behavior still on librdkafka 2.3. I can see that the commit you pushed 4503dcf was never merged and looking at the main branch, I cannot see these changes there. Also, there's no mention of this in the v1.7.0 changelog which leads me to believe that the issue was not actually fixed. Edit: I tried to apply 4503dcf to librdkafka 2.3.0 (the version I was using) and now the issue is gone. |
There is a bug in librdkafka where producing the very first message into a topic always takes around 1 second. This happens due to bug that was first raised in this GitHub issue: confluentinc/librdkafka#3202 The maintainer proposed a fix for this problem and said it was going to be fixed starting librdkafka 1.7.0, but it seems the fix was actually never merged since the problem still existed. I think that the maintainer mixed something up there because they actually closed the issue, perhaps they forgot to merge the fix or something similar. This commit makes rdkafka use our fork of librdkafka 2.3.0. This fork is almost identical to the regular 2.3.0 but it has the same fix applied that the maintainer proposed. You can find the commit here: salemove/librdkafka@71eea91 XT-59
There is a bug in librdkafka where producing the very first message into a topic always takes around 1 second. This happens due to bug that was first raised in this GitHub issue: confluentinc/librdkafka#3202 The maintainer proposed a fix for this problem and said it was going to be fixed starting librdkafka 1.7.0, but it seems the fix was actually never merged since the problem still existed. I think that the maintainer mixed something up there because they actually closed the issue, perhaps they forgot to merge the fix or something similar. This commit makes rdkafka use our fork of librdkafka 2.3.0. This fork is almost identical to the regular 2.3.0 but it has the same fix applied that the maintainer proposed. You can find the commit here: salemove/librdkafka@71eea91 XT-59
Description
Hello,
I have a use case where I need to send a single message with no (minimal) delay. I have tried setting linger.ms configuration setting to 0, and am calling produce() then immediately flush(-1) but sending still takes about 800ms. The message is only a few hundred bytes. I have not set any other configuration settings (beside bootstrap.servers)
librdkafka++ 1.5.0 on Redhat Enterprise Linux 7
Log output with "debug" "protocol"
%7|1609942113.294|CONNECTED|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/bootstrap: Connected (#1)
%7|1609942113.294|FEATURE|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/bootstrap: Updated enabled protocol features +ApiVersion to ApiVersion
%7|1609942113.294|SEND|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/bootstrap: Sent ApiVersionRequest (v3, 40 bytes @ 0, CorrId 1)
%7|1609942113.295|RECV|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/bootstrap: Received ApiVersionResponse (v3, 344 bytes, CorrId 1, rtt 0.50ms)
%7|1609942113.295|SEND|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/bootstrap: Sent MetadataRequest (v4, 26 bytes @ 0, CorrId 2)
%7|1609942113.295|RECV|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/bootstrap: Received MetadataResponse (v4, 109 bytes, CorrId 2, rtt 0.23ms)
2021-01-06 08:08:33.453 calling produce()
2021-01-06 08:08:33.453 calling flush()
%7|1609942114.293|SEND|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/55: Sent MetadataRequest (v4, 53 bytes @ 0, CorrId 3)
%7|1609942114.293|RECV|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/55: Received MetadataResponse (v4, 169 bytes, CorrId 3, rtt 0.35ms)
%7|1609942114.294|SEND|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/55: Sent ProduceRequest (v7, 12392 bytes @ 0, CorrId 4)
%7|1609942114.294|RECV|rdkafka#producer-1| [thrd:xxxx:9092/bootstrap]: xxxx:9092/55: Received ProduceResponse (v7, 69 bytes, CorrId 4, rtt 0.67ms)
%7|1609942116.300|DESTROY|rdkafka#producer-1| [thrd:app]: Terminating instance (destroy flags none (0x0))
%7|1609942116.300|DESTROY|rdkafka#producer-1| [thrd:main]: Destroy internal
%7|1609942116.300|DESTROY|rdkafka#producer-1| [thrd:main]: Removing all topics
Many Thanks
The text was updated successfully, but these errors were encountered: