[
https://issues.apache.org/jira/browse/QPID-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156852#comment-13156852
]
Alex Rudyy commented on QPID-3642:
----------------------------------
Keith,
> 1) Can you extract the separate bug fix we discussed into a separate
> Jira/patch?
I extracted changes into 2 patches.
The first patch adds DLQ & max delivery count functionality for 0-8/0-9/0-9-1
paths.
The second patch adds DLQ & max delivery count functionality for 0-10 paths.
Also, in second patch I fixed issue with setting of re-delivery flag for
pre-fetched messages(QPID-3640).
> 2) AMQBrokerManagerMBean#createNewQueue surely the old method should call the
> new override, and avoid duplicating the method.
Fixed.
> 3) AMQConnection.java could you document that rejectBehaviour member only
> applies to 0-8..0-9-1.
I moved getRejectBehaviour functionality from AMQConnection into
BasicMessageConsumer_0_8 as it is the place where it is needed.
However, I could not moved AMQDestinaton#getRejectBehaviour into
BasicMessageConsumer, so, I added more commentaries about "rejectbehaviour"
option in AMQDestinaton.
> Implement Dead Letter Queue functionality
> -----------------------------------------
>
> Key: QPID-3642
> URL: https://issues.apache.org/jira/browse/QPID-3642
> Project: Qpid
> Issue Type: New Feature
> Components: Java Broker, Java Client
> Reporter: Alex Rudyy
> Assignee: Alex Rudyy
> Fix For: 0.15
>
> Attachments:
> 0001-QPID-3642-QPID-3643-Add-Dead-Letter-Queue-functional.patch,
> 0002-QPID-3642-QPID-3640-Add-Dead-Letter-Queue-functional.patch
>
>
> Implement functionality to move messages into Dead Letter Queue on reaching
> Max Delivery Count limit.
> The Maximum Delivery Count is a property of a queue. If the client
> application is unable to process a message more than a specified number of
> times, the then the broker either moves the message to the specified DLQ, or
> it is dropped (producing an operation log message).
> If the application is unable to process a message it must call either
> Session#recover() or Session#rollback() (depending on transactionality) on
> the Session in use. If during recovery the broker discovers that a message
> has been seen (at least) the maximum number of times then it will move the
> message to the DLQ or drop the message, depending on how the queue is
> configured.
> This feature can be enabled for a queue either through the XML configuration
> for the broker, or when declaring the queue using JMX. It is also necessary
> to enable a setting on the client. The feature is available for both
> synchronous consumers (i.e. those using MessageConsumer#receive()) and
> asynchronous consumers (i.e. those implementing MessageListener#onMessage)
> using all JMS delivery modes.
> When enabled for a given queue, the DLQ feature causes generation of a Dead
> Letter Exchange and a Dead Letter Queue, named according to the convention
> <queue_name>_DLE and <queue_name>_DLQ. If the client indicates it no longer
> wishes the receive the message (by means of the Max Delivery Count feature)
> then the message is routed through the dead letter exchange onto the DLQ and
> removed from the original queue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
