[ 
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:

    https://github.com/apache/qpid-dispatch/pull/172#discussion_r126158278
  
    --- 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
(v6.4.14#64029)

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

Reply via email to