qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages
Date Fri, 07 Jul 2017 15:42:00 GMT

    [ https://issues.apache.org/jira/browse/DISPATCH-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078261#comment-16078261

ASF GitHub Bot commented on DISPATCH-767:

Github user alanconway commented on a diff in the pull request:

    --- Diff: src/message_private.h ---
    @@ -94,10 +94,19 @@ typedef struct {
         unsigned char       *parse_cursor;
         qd_message_depth_t   parse_depth;
         qd_parsed_field_t   *parsed_message_annotations;
    +    bool                 discard;                        // Should this message be discarded?
    +    bool                 receive_complete;               // true if the message has been
completely received, false otherwise
    +    unsigned int         fanout;                         // The number of receivers for
this message. This number does not include in-process subscribers.
     } qd_message_content_t;
     typedef struct {
         DEQ_LINKS(qd_message_t);   // Deque linkage that overlays the qd_message_t
    +    qd_field_location_t   cursor;           // A pointer to the current location of the
outgoing byte stream.
    +    qd_message_depth_t    message_depth;
    --- End diff --
    Add a comment to explain these here - not obvious (to me) what they mean.

> 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

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message