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

ASF GitHub Bot commented on DISPATCH-1045:
------------------------------------------

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

    https://github.com/apache/qpid-dispatch/pull/328#discussion_r198613623
  
    --- Diff: src/router_node.c ---
    @@ -312,12 +307,30 @@ static void AMQP_rx_handler(void* context, qd_link_t 
*link)
                            pn_link_name(pn_link));
             }
     
    +        //
    +        // The entire message has been received and we are ready to 
consume the delivery by calling pn_link_advance().
    +        //
    +        pn_link_advance(pn_link);
    +
    +        //
    +        // The entire message has been received but this message needs to 
be discarded
    +        //
    +        if (qd_message_is_discard(msg)) {
    +            pn_delivery_update(pnd, qdr_delivery_disposition(delivery));
    --- End diff --
    
    Agreed. I have pushed up a new commit to remedy your comment. Please take a 
quick look. Thanks.


> Sometimes close connetion after releasing partial multi-frame messsage
> ----------------------------------------------------------------------
>
>                 Key: DISPATCH-1045
>                 URL: https://issues.apache.org/jira/browse/DISPATCH-1045
>             Project: Qpid Dispatch
>          Issue Type: Bug
>          Components: Router Node
>    Affects Versions: 1.1.0
>            Reporter: Alan Conway
>            Assignee: Ganesh Murthy
>            Priority: Major
>             Fix For: 1.2.0
>
>
> Since DISPATCH-1012 the router releases undeliverable deliveries.
> In the case of a multi-frame delivery, it is possible for dispatch to release 
> it before the entire delivery has been received. Presently dispatch settles 
> such deliveries and advances its link. That means that if another transfer 
> for the same delivery arrives, dispatch regards it as a new message with an 
> invalid delivery-id and closes the connection. Since the release is 
> asynchronous, there's no way for the client to avoid this possibility.
> Worth checking the spec but I suspect we should be dropping the extra data 
> rather than closing the connection. Need to investigate how this would work 
> in proton - I think we'd update the delivery without settling it and then 
> wait for the remote to settle before finally throwing it away.
>  



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

Reply via email to