[
https://issues.apache.org/jira/browse/DISPATCH-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078262#comment-16078262
]
ASF GitHub Bot commented on DISPATCH-767:
-----------------------------------------
Github user alanconway commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/172#discussion_r126168949
--- Diff: src/message.c ---
@@ -1151,89 +1287,140 @@ void qd_message_send(qd_message_t *in_msg,
{
qd_message_pvt_t *msg = (qd_message_pvt_t*) in_msg;
qd_message_content_t *content = msg->content;
- qd_buffer_t *buf = DEQ_HEAD(content->buffers);
- unsigned char *cursor;
+ qd_buffer_t *buf = 0;
pn_link_t *pnl = qd_link_pn(link);
- qd_buffer_list_t new_ma;
- DEQ_INIT(new_ma);
+ // How many receivers does this message have?
+ int fanout = qd_message_fanout(in_msg);
- // Process the message annotations if any
- compose_message_annotations(msg, &new_ma, strip_annotations);
+ if (msg->sent_depth < QD_DEPTH_MESSAGE_ANNOTATIONS) {
+ //
+ // Start with the very first buffer;
+ //
+ buf = DEQ_HEAD(content->buffers);
--- End diff --
No lock here? What's the protocol for protecting buffers between
send/receive threads? We can't let threads work concurrently on the same buffer
(in particular change the buffer size) We could lock the use of buffers, not
just the enqueue/deque, or there are some other options.
> Message Cut-Through/Streaming for efficient handling of large messages
> ----------------------------------------------------------------------
>
> Key: DISPATCH-767
> URL: https://issues.apache.org/jira/browse/DISPATCH-767
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Router Node
> Reporter: Ted Ross
> Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> When large, multi-frame messages are sent through the router, there is no
> need to wait for the entire message to arrive before starting to send it
> onward.
> This feature causes the router to route the first frame and allow subsequent
> frames in a delivery to be streamed out in pipeline fashion. Ideally, the
> memory usage in the router should only involve pending frames. This would
> allow the router to handle arbitrary numbers of concurrent arbitrarily large
> messages.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
