qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rafael H. Schloming (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PROTON-33) Provide API for user managed pn_message_t payload/memory
Date Thu, 17 Oct 2013 18:12:44 GMT

     [ 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

View raw message