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-1045) Sometimes close connetion after releasing partial multi-frame messsage
Date Wed, 27 Jun 2018 19:28:00 GMT

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

    --- Diff: src/router_node.c ---
    @@ -312,12 +307,30 @@ static void AMQP_rx_handler(void* context, qd_link_t *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.

> 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

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

View raw message