[jira] [Commented] (PROTON-1823) [c] make it easier to send a message

2018-05-23 Thread ASF subversion and git services (JIRA) 

[ 
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

2018-04-10 Thread Alan Conway (JIRA) 

[ 
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

2018-04-10 Thread Andrew Stitcher (JIRA) 

[ 
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

2018-04-10 Thread ASF subversion and git services (JIRA) 

[ 
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

2018-04-09 Thread Alan Conway 
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

2018-04-06 Thread Justin Ross (JIRA) 

[ 
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

2018-04-06 Thread ASF subversion and git services (JIRA) 

[ 
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

2018-04-06 Thread ASF subversion and git services (JIRA) 

[ 
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