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