[jira] [Commented] (PROTON-1823) [c] make it easier to send a message
[ https://issues.apache.org/jira/browse/PROTON-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487660#comment-16487660 ] ASF subversion and git services commented on PROTON-1823: - Commit ecc446839fad05990b630c25393db355f67bf0b0 in qpid-proton's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ecc4468 ] PROTON-1823: Mark the new API element unsettled > [c] make it easier to send a message > > > Key: PROTON-1823 > URL: https://issues.apache.org/jira/browse/PROTON-1823 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.23.0 > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > Supports the following 2 scenarios: > 1. Simple: don't care about allocations, just send `pn_message_t *msg` and > forget it: > pn_message_send(msg, sender, NULL) > 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > ... > pn_message_send(msg, sender, ); // Expand as needed > pn_message_send(msg2, sender2, ); // etc. > ... > free(buffer->start); // Application must do final free of buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1823) [c] make it easier to send a message
[ https://issues.apache.org/jira/browse/PROTON-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433027#comment-16433027 ] Alan Conway commented on PROTON-1823: - Fixed by commits: [https://github.com/alanconway/qpid-proton/commit/bdd986a1] [https://github.com/alanconway/qpid-proton/commit/c7717a47] > [c] make it easier to send a message > > > Key: PROTON-1823 > URL: https://issues.apache.org/jira/browse/PROTON-1823 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.23.0 > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > Supports the following 2 scenarios: > 1. Simple: don't care about allocations, just send `pn_message_t *msg` and > forget it: > pn_message_send(msg, sender, NULL) > 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > ... > pn_message_send(msg, sender, ); // Expand as needed > pn_message_send(msg2, sender2, ); // etc. > ... > free(buffer->start); // Application must do final free of buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1823) [c] make it easier to send a message
[ https://issues.apache.org/jira/browse/PROTON-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432872#comment-16432872 ] Andrew Stitcher commented on PROTON-1823: - [~aconway] You might want to consider adding a test to send a message long enough to make the buffer reallocate (noticed this is missing from the coverage run). > [c] make it easier to send a message > > > Key: PROTON-1823 > URL: https://issues.apache.org/jira/browse/PROTON-1823 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.23.0 > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > Supports the following 2 scenarios: > 1. Simple: don't care about allocations, just send `pn_message_t *msg` and > forget it: > pn_message_send(msg, sender, NULL) > 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > ... > pn_message_send(msg, sender, ); // Expand as needed > pn_message_send(msg2, sender2, ); // etc. > ... > free(buffer->start); // Application must do final free of buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1823) [c] make it easier to send a message
[ https://issues.apache.org/jira/browse/PROTON-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16432676#comment-16432676 ] ASF subversion and git services commented on PROTON-1823: - Commit c7717a47d675bae12fcfbf31244009ddb247787c in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c7717a4 ] PROTON-1823: [c] pn_message_send() calls pn_link_advance() Call pn_link_advance() at the end of pn_message_send() Since pn_message_send() can only send complete messages, it makes no sense to call it without calling pn_link_advance(). > [c] make it easier to send a message > > > Key: PROTON-1823 > URL: https://issues.apache.org/jira/browse/PROTON-1823 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.23.0 > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > Supports the following 2 scenarios: > 1. Simple: don't care about allocations, just send `pn_message_t *msg` and > forget it: > pn_message_send(msg, sender, NULL) > 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > ... > pn_message_send(msg, sender, ); // Expand as needed > pn_message_send(msg2, sender2, ); // etc. > ... > free(buffer->start); // Application must do final free of buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [jira] [Commented] (PROTON-1823) [c] make it easier to send a message
On Fri, Apr 6, 2018 at 9:05 PM, Justin Ross (JIRA)wrote: > > [ https://issues.apache.org/jira/browse/PROTON-1823?page= > com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel=16429180#comment-16429180 ] > > Justin Ross commented on PROTON-1823: > - > > This is really nice! > > > [c] make it easier to send a message > > > > > > Key: PROTON-1823 > > URL: https://issues.apache.org/jira/browse/PROTON-1823 > > Project: Qpid Proton > > Issue Type: Improvement > > Components: proton-c > >Affects Versions: proton-c-0.22.0 > >Reporter: Alan Conway > >Assignee: Alan Conway > >Priority: Minor > > Fix For: proton-c-0.23.0 > > > > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > > Supports the following 2 scenarios: > > 1. Simple: don't care about allocations, just send `pn_message_t *msg` > and forget it: > > pn_message_send(msg, sender, NULL) > > 2. Efficient: re-use a buffer, buffer is allocated and expanded as > required: > > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > > ... > > pn_message_send(msg, sender, ); // Expand as needed > > pn_message_send(msg2, sender2, ); // etc. > > ... > > free(buffer->start);// Application must do final free of > buffer > > > Since you like that here's another thought - add a public API for just the "encode" part of pn_message_send() but allow the user to specify the realloc function. This covers two slightly more complicated cases with one extra API function, the implementation is already written in pn_message_send: 1. encode a message but don't send it immediately (e.g. because I have my own in-memory message queues and don't want to hold up the proton IO thread with the encoding work - which is among the most CPU intensive things proton does) pn_message_encode_realloc(msg, , realloc); /* standard realloc */ pn_link_send(sender, mybuf.start, mybuf.size); /*later*/ 2. User your own allocator pn_message_encode_realloc(msg, , _realloc_fn); Originally I thought about adding a 'realloc' parameter to pn_message_send itself, but that makes the simple cases less simple. By adding a separate function that encodes, but doesn't send, we keep those cases simple but kill 2 other birds with one stone (encoding outside the proton thread and using your own allocator.) Of course all this can be done directly by the user with the existing pn_message_encode(), but it's about 25 error-prone lines so maybe worth simplifying for something so common.
[jira] [Commented] (PROTON-1823) [c] make it easier to send a message
[ https://issues.apache.org/jira/browse/PROTON-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429180#comment-16429180 ] Justin Ross commented on PROTON-1823: - This is really nice! > [c] make it easier to send a message > > > Key: PROTON-1823 > URL: https://issues.apache.org/jira/browse/PROTON-1823 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.23.0 > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > Supports the following 2 scenarios: > 1. Simple: don't care about allocations, just send `pn_message_t *msg` and > forget it: > pn_message_send(msg, sender, NULL) > 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > ... > pn_message_send(msg, sender, ); // Expand as needed > pn_message_send(msg2, sender2, ); // etc. > ... > free(buffer->start); // Application must do final free of buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1823) [c] make it easier to send a message
[ https://issues.apache.org/jira/browse/PROTON-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429052#comment-16429052 ] ASF subversion and git services commented on PROTON-1823: - Commit bdd986a1d8da5b5b0811aa244d974f48a757e3d7 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bdd986a ] PROTON-1823: [c] pn_message_send() simplified message sending for C Encapsulates the awkward allocate-encode-expand dance required by pn_message_encode() Supports the following 2 scenarios: 1. Simple: don't care about allocations, just send `pn_message_t *msg` and forget it: pn_message_send(msg, sender, NULL) 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: pn_rwbytes_t buffer={0}; // Zero initialize, libary will do the allocation ... pn_message_send(msg, sender, ); // Expand as needed pn_message_send(msg2, sender2, ); // etc. ... free(buffer->start);// Application must do final free of buffer Note 2. assumes use of malloc/realloc/free, apps that need custom allocation can use the original pn_message_encode() API or we could add a version that takes a pointer to a function equivalent to realloc() Updated examples to use this API. > [c] make it easier to send a message > > > Key: PROTON-1823 > URL: https://issues.apache.org/jira/browse/PROTON-1823 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.23.0 > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > Supports the following 2 scenarios: > 1. Simple: don't care about allocations, just send `pn_message_t *msg` and > forget it: > pn_message_send(msg, sender, NULL) > 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > ... > pn_message_send(msg, sender, ); // Expand as needed > pn_message_send(msg2, sender2, ); // etc. > ... > free(buffer->start); // Application must do final free of buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1823) [c] make it easier to send a message
[ https://issues.apache.org/jira/browse/PROTON-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16429036#comment-16429036 ] ASF subversion and git services commented on PROTON-1823: - Commit dc724c140d23158ac3059292b27962cc276acdc8 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=dc724c1 ] PROTON-1823: [c] pn_message_send() simplified message sending for C Encapsulates the awkward allocate-encode-expand dance required by pn_message_encode() Supports the following 2 scenarios: 1. Simple: don't care about allocations, just send `pn_message_t *msg` and forget it: pn_message_send(msg, sender, NULL) 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: pn_rwbytes_t buffer={0}; // Zero initialize, libary will do the allocation ... pn_message_send(msg, sender, ); // Expand as needed pn_message_send(msg2, sender2, ); // etc. ... free(buffer->start);// Application must do final free of buffer Note 2. assumes use of malloc/realloc/free, apps that need custom allocation can use the original pn_message_encode() API or we could add a version that takes a pointer to a function equivalent to realloc() Updated examples to use this API. > [c] make it easier to send a message > > > Key: PROTON-1823 > URL: https://issues.apache.org/jira/browse/PROTON-1823 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.23.0 > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > Supports the following 2 scenarios: > 1. Simple: don't care about allocations, just send `pn_message_t *msg` and > forget it: > pn_message_send(msg, sender, NULL) > 2. Efficient: re-use a buffer, buffer is allocated and expanded as required: > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > ... > pn_message_send(msg, sender, ); // Expand as needed > pn_message_send(msg2, sender2, ); // etc. > ... > free(buffer->start); // Application must do final free of buffer -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org