On 29 June 2017 at 21:27, Xin Chen <[email protected]> wrote: > Is the following NOT allowed per the spec? > > transfer(handle=0, delivery-tag=[], delivery-id=1, message-format=0, > settled=true, more=true, ...) > transfer(handle=0, more=true) > transfer(handle=0, more=false) > transfer(handle=0, delivery-tag=[], delivery-id=2, message-format=0, > settled=true, more=true, ...) > transfer(handle=0, more=true) > transfer(handle=0, more=false) > > > I believe (as one of the spec authors, for what that is worth) that case is allowed. This is essentially the same as
transfer(handle=0, delivery-tag=[], delivery-id=1, message-format=0,settled=true, more=false) transfer(handle=0, delivery-tag=[], delivery-id=2, message-format=0,settled=true, more=false) which is definitely allowed. -- Rob PS I shall add Xin's comment and this reply to the JIRA in case it gets lost here > > On Thu, Jun 29, 2017 at 6:26 AM, Alex Rudyy (JIRA) <[email protected]> > wrote: > > > > > [ https://issues.apache.org/jira/browse/QPID-6653?page= > > com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > > > Alex Rudyy closed QPID-6653. > > ---------------------------- > > Resolution: Invalid > > > > Closing this JIRA as invalid, as per AMQP spec (section 2.6.12) : "The > > delivery-tag MUST be unique amongst all deliveries that could be > considered > > unsettled by either end of the link.". > > The commit [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git > ; > > h=0598f7e ] made against QPID-6653 adds a verification of tag uniqueness, > > and, closes the link with error if unsettled delivery with a duplicate > tag > > is received. > > > > > Earlier Qpid Java client: receiver issue with multi-transfer > pre-settled > > messages > > > ------------------------------------------------------------ > > --------------------- > > > > > > Key: QPID-6653 > > > URL: https://issues.apache.org/jira/browse/QPID-6653 > > > Project: Qpid > > > Issue Type: Bug > > > Components: Java Broker > > > Affects Versions: 0.32 > > > Reporter: Xin Chen > > > Fix For: qpid-java-broker-7.0.0 > > > > > > Attachments: ReceivingLinkEndpoint.java > > > > > > > > > This issue is regarding the Qpid Java client released as part of the > > Qpid JMS 0.32. https://qpid.apache.org/releases/qpid-0.32/index.html > > > When the remote peer sends settled message with multiple transfer > > frames, it could use the same delivery tag (e.g. an empty binary) for all > > messages. The ReceivingLinkEndpoint class keeps track of both unsettled > > deliveries and partially received deliveries in two maps, _unsettledIds > and > > _unsettledMap. When user acknowledges a message by calling > > Receiver.acknowledge(Message), the state of the delivery is removed from > > both maps. This is causing a problem if the user acknowledges a > previously > > received message and a new message is being partially received (because > > they share the same delivery tag). The observed symptom is receiver stuck > > and NullPointerException from connection's frame pump when decoding frame > > buffers. > > > I attempted a fix by using a new variable to remember the last received > > partial delivery, if any, and only putting unsettled deliveries into the > > two maps. It worked in this particular scenario. The existing tests are > > passing with this change but I am not completely sure if it has any side > > effects. > > > I will attach a modified ReceivingLinkEndpoint.Java file so you can > take > > a look. > > > > > > > > -- > > This message was sent by Atlassian JIRA > > (v6.4.14#64029) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
