[ 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: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org