qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Godfrey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6653) Earlier Qpid Java client: receiver issue with multi-transfer pre-settled messages
Date Sat, 10 Dec 2016 17:26:58 GMT

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

Rob Godfrey commented on QPID-6653:

This client is no longer supported and has been replaced by the Qpid JMS client.  However
this issue would potentially also affect the Java Broker as it uses the same code, so I am
assigning this JIRA to the Java Broker for review

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

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

View raw message