[
https://issues.apache.org/jira/browse/QPID-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040702#comment-14040702
]
ASF subversion and git services commented on QPID-5828:
-------------------------------------------------------
Commit 1604785 from [~gsim] in branch 'qpid/trunk'
[ https://svn.apache.org/r1604785 ]
QPID-5828: Ensure that we don't try to check status of null completion handle
> qpid::Messaging API Sender/Receiver assorted bugs
> -------------------------------------------------
>
> Key: QPID-5828
> URL: https://issues.apache.org/jira/browse/QPID-5828
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.28
> Reporter: Clive Lilley
> Assignee: Gordon Sim
> Priority: Minor
> Fix For: Future
>
> Attachments: messaging.tar.gz
>
>
> Several issues with the qpid::messaging::Sender and qpid::messaging::Receiver
> implementations.
> Summarized below:
> - TTL on a message does not get adjusted when stored in the outgoing
> Sender queue and the queue cannot be emptied due to broker unavailability.
> - TTL on messages that expire while they are cached in the receivers queue.
> Messages still get delivered even though they have expired.
> - getUnsettled segmentation error when called with no connection to
> broker but messages in the Sender outgoing queue (fine with zero size
> outbound queue).
> - Inconsistent behavior of Sender when Broker not connected. When
> sending a message an Exception occurs, as no connection, but messages
> are still placed in outbound queue up until the Sender is flushed
> ('window < Capacity/4' , not sure where the 4 comes from). At this point
> any further sent messages still cause an exception, but messages do not
> get placed in the outbound queue. Varying the capacity varies when this
> occurs and so doesn't seem correct.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
