[
https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming updated PROTON-33:
--------------------------------------
Priority: Major (was: Blocker)
> Provide API for user managed pn_message_t payload/memory
> --------------------------------------------------------
>
> Key: PROTON-33
> URL: https://issues.apache.org/jira/browse/PROTON-33
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Reporter: William Henry
> Labels: api
>
> Some users will have their own frameworks and methods of managing the data
> received.
> Currently in the pn_message_t the only way to get at the payload/data is to
> call pn_message_save with a pre-allocated buffer of data. pn_message_save
> copies to that data buffer and returns the actual size. (so for example if I
> passed an allocated buffer of 1028 I might be returned 8 bytes).
> In many situations this alloc is expensive - especially when integrating with
> established frameworks that already do the copy - now there are two allocs.
> I suggest an API call that returns the message payload as a pointer. There
> is a risk that this might get deleted and a pn_message_t should check that
> it's buffer is still valid (I assume it would.) In the case I'm looking at
> the "other" framework is merely making it's own copy but doesn't free the
> memory (but, as I said, there is a risk it could).
> I'm willing to debate pn_message_t having an API that returns a copy but I
> imagine many users will any up complaining about the alloc in the that API
> call.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
