Kafka 0.11.0.0 added the concept of record headers (separate from the payload):
https://issues.apache.org/jira/browse/KAFKA-4208
The Java API was updated to support this. This request is to add support for reading/sending this headers in librdkafka.
To vote for this issue add a 馃憤 reaction to this comment
Header support is on the backlog but not yet prioritized.
It would be useful to know how you expect to use it, please fill out the following template (copy it to a comment):
We are using Kafka as part of a microservice architecture to publish events. Currently I am sending header information within the payload, with the main values being:
Typical number of headers per message: 2-4
Thanks
We currently are sending an RTP header within the payload. Contains timestamp,sequence number, source of the payload.
Would like the following:
Add header
Delete header (by name)
Alter/Update header value (by name)
Get/read header (by name)
Enumerate headers
鈥ypical number of headers per message: 2
鈥ypical size of header value: 12 or 16 bytes, for another payload roughly 512
Typical number of headers per message: 2-4
Typical size of header value: 10-30 bytes
We're planning to use this for distributed tracing, among other scenarios.
Typical number of headers per message: <5
Typical size of header value: ids, possibly uuids (nothing big)
Headers support is now on master, please try it out.
Thank you very much. I will download and give her a shot.
Mike Warnock
[email protected]
When is the next official release expected to try headers. We can only upgrade to official release and not work with master.
@kparadkar We're aiming for a release mid february the earliest.
The more people that gives new features a spin before that the better, making sure we cover all use-cases.
Thanks for implementing this. I have started work to use this new feature, and noted some difficulty in doing so as I have been using the C++ bindings.
Currently, using the C++ bindings, I cannot "safely" access the rd_kafka_message_t pointer needed to call the newly implemented C functions (the Message class does not offer a method for accessing rd_kafka_message_t). As a workaround, it appears I could reasonably safely cast Message to MessageImpl, and then access the public rd_kafka_message_t pointer from there.
Any thoughts on adding C++ support for headers? Or any other tips on how to safely utilize the existing api from C++?
The cast workaround is fragile so I would not recommend it.
The plan is to add proper headers support to the C++ API, but before that happens we could expose a c_ptr() method on the Message object to return the rd_kafka_message_t pointer. I'm adding the same for rd_kafka_t and rd_kafka_topic_t just for this reason, where the C++ API is lagging behind the C API.
Yeah, I definitely saw the cast as fragile and unsafe. The c_ptr() method seems like a good way to permit access to the latest C features, before they have been fully encapsulated.
Thanks
Hi guys! Could someone share example of producing message with headers using C++ binding of the library? Thx in advance.
Headers are not yet supported in the C++ API, only in C.
The C++ API typically lags behind the C API and features are added on community demand, or the community contributions.
@edenhill Thx for the answer. So, there is no way to pass headers to produced msg rather than extend C++ interface. Right? (even with workaround like for reading headers of consumed message poiting to C ptr).
You can access the underlying C rd_kafka_t handle with c_ptr() and then call rd_kafka_producev() with a headers list or individual headers.
You can still use your existing DeliveryReport C++ classes to handle the responses and everything else.
I see. Thx for help!
Thank you again for providing this support. The C lib worked perfectly. After sending each message with a kafka header, I had to call rd_kafka_headers_destory following by rd_kafka_headers_new(1) in order to create new values and to avoid double frees.
The produce headers are owned by the application.
Most helpful comment
Headers support is now on master, please try it out.