qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gordon Sim (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PROTON-841) C recv example does not return disposition state
Date Tue, 24 Mar 2015 17:15:52 GMT

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

Gordon Sim commented on PROTON-841:

You can set the incoming window  for messenger and then accept (or reject) explicitly.

FWIW what the qpid c++ broker does in the case described is treat the settlement as positive
acknowledgement (i.e. as accept) if no explicit disposition is specified.

> C recv example does not return disposition state
> ------------------------------------------------
>                 Key: PROTON-841
>                 URL: https://issues.apache.org/jira/browse/PROTON-841
>             Project: Qpid Proton
>          Issue Type: Bug
>            Reporter: Matt Broadstone
> I apologize that I can't dig deeper into this for you, but I'm pressed for time and figured
it would still be meaningful feedback. I was recently testing the rabbitmq amqp1.0 module
against a number of amqp 1.0 clients, and realized that when using the send/recv examples
for the messenger api in proton my recv client was disconnecting immediately after receiving
a message. 
> I submitted this [issue](https://github.com/rabbitmq/rabbitmq-amqp1.0/issues/8) to rabbitmq's
github and we traced the issue down to the fact that proton was not sending back a state in
the settled disposition frame upon receipt of the message from the "send" client. The spec
is incredibly ambiguous about what to do in this scenario for brokers, and specifies that
state is an optional field, but at the same time the broker has no idea whether the message
has been acknowledged or rejects, simply that it has been settled. 
> Not sure how you guys want to go about this in your project, rabbitmq gracefully handles
this problem by closing the channel at this point (rather than crashing as it did previously).
> Anyway, just letting you know!
> Cheers

This message was sent by Atlassian JIRA

View raw message