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

Could Message provide payload_mut? #95

Closed
frankmcsherry opened this issue Aug 20, 2018 · 2 comments · Fixed by #375
Closed

Could Message provide payload_mut? #95

frankmcsherry opened this issue Aug 20, 2018 · 2 comments · Fixed by #375

Comments

@frankmcsherry
Copy link

I'm not a Kafka expert, but looking at the various bits and pieces, it seems possible that the Message trait could provide a

    fn payload_mut(&mut self) -> Option<&mut [u8]>;

Looking at the RdKafka::Message docs, it looks like the payload() method returns a void* without a const modifier (unlike the key_ptr() method which is const void*). My C++ is not super-strong, but my sense is that this signature means that one can safely mutate the results of payload().

The motivation might be limited, but it saves a copy for me (Abomonation does deserialization using in-place pointer correction). If it is a no-brainer, then great! If it is weird and mysterious and scary, I can understand that too.

@thijsc
Copy link
Collaborator

thijsc commented Aug 22, 2018

Actually this library wraps the C interface, so this is the relevant doc: https://docs.confluent.io/2.0.1/clients/librdkafka/structrd__kafka__message__t.html

Otherwise I have no idea if this is safe, the docs don't make that clear. We should probably ask over at librdkafka.

@benesch
Copy link
Collaborator

benesch commented Oct 28, 2019

The official word is in:

There are currently no constraints to modifying the per-message key/payload as long as honouring the key/payload lengths, but this should be considered and implementation detail and there are no formal guarantees that this will continue to be the case in future versions.

In practice I don't see a reason why this would ever change though.

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 a pull request may close this issue.

3 participants