Brent, Redeliveries aren't something that I go very deep on, but https://activemq.apache.org/message-redelivery-and-dlq-handling only lists four ways that redelivery should occur, and only #2 seems like it should be applicable to the situation where the client connection closes abruptly. #2 involves the use of transactions, which I know you said you wanted to avoid, but I'd suggest you try that to at least find out if it's a viable (if undesirable) option.
You're also welcome to submit an enhancement request in JIRA to ask for the behavior you're interested in. But I'll warn you that off the top of my head, I can't think of a way to distinguish from the broker side of the connection between a client who crashed while processing the message and a client who disconnected before attempting to process the message (where marking the message as redelivered would be incorrect behavior), I'm not sure that such an enhancement would be implemented. So if there's a built-in way to get the behavior you want, that seems like the way to go even if it involves using a feature that you'd prefer to avoid. Tim On Tue, Oct 6, 2020, 9:18 AM Kilgore, Brent (CGI Federal) < brent.kilg...@cgifederal.com> wrote: > I am having a lot of difficulty getting limited retries and dead letter > queues to work in ActiveMQ. I am developing using the activemq-cpp library > in linux. > > Versions: > * ActiveMQ 5.15.9 > * Activemq-cpp 3.9.4 > > This is what I want to do: > *set DLQ and retry policies on the broker (xml below, schedulerSupport > enabled) > *register a cms::MessageListener against a queue using Auto-acknowledge > *Have the message get redelivered during segfault according to below > policy. > > I would really prefer not to have to: > * use transactional messaging (commit/rollback.. the other ack modes might > be acceptable) > * handle the retry logic at client side (due to segfault possibility) > > What I am observing: > *When the cpp exe crashes with segfault, the message is returned to queue > without delay and is never routed to DLQ no matter how *many redeliveries. > This means the server goes into an infinite crash loop with the poisoned > message. > *If the handleMessage call completes, the message disappears as expected. > > Thanks > > --------------------------------------------------------- > (broker tag has schedulersupport="true") > > > <destinationPolicy> > <policyMap> > <policyEntries> > <policyEntry topic=">"> > <subscriptionRecoveryPolicy> > <fixedCountSubscriptionRecoveryPolicy > maximumSize="100" /> > </subscriptionRecoveryPolicy> > <!-- The constantPendingMessageLimitStrategy is used > to prevent > slow topic consumers to block producers and > affect other consumers > by limiting the number of messages that are > retained > For more information, see: > > > http://activemq.apache.org/slow-consumer-handling.html > --> > <pendingMessageLimitStrategy> > <constantPendingMessageLimitStrategy limit="1000" > /> > </pendingMessageLimitStrategy> > </policyEntry> > <policyEntry queue=">_REQ"> > <deadLetterStrategy> > <!-- > Use the prefix 'DLQ.' for the destination name, > and make > the DLQ a queue rather than a topic. expire > after 7 days > (604,800,000 ms) > --> > <individualDeadLetterStrategy queuePrefix="DLQ." > useQueueForQueueMessages="true" expiration="604800000" > processNonPersistent="true" /> > </deadLetterStrategy> > </policyEntry> > </policyEntries> > </policyMap> > </destinationPolicy> > > ... > > <plugins> > <redeliveryPlugin fallbackToDeadLetter="true" > sendToDlqIfMaxRetriesExceeded="true"> > <redeliveryPolicyMap> > <redeliveryPolicyMap> > <!-- > <redeliveryPolicyEntries> > <!-x- a destination specific policy -x-> > <redeliveryPolicy queue="SpecialQueue" > maximumRedeliveries="4" > redeliveryDelay="10000"/> > </redeliveryPolicyEntries> > --> > <defaultEntry> > <!-- the fallback policy for all other > destinations --> > <redeliveryPolicy maximumRedeliveries="4" > initialRedeliveryDelay="1000" > redeliveryDelay="5000"/> > </defaultEntry> > </redeliveryPolicyMap> > </redeliveryPolicyMap> > </redeliveryPlugin> > </plugins> > Proprietary/confidential information belonging to CGI Federal Inc. or its > affiliates may be contained in this message. If you are not a recipient > indicated or intended in this message (or responsible for the delivery of > this message to such person), or if you think for any reason that this > message may have been addressed to you in error, you may not use or copy or > deliver this message to anyone else. In such case, you should destroy this > message and are asked to notify the sender by reply email. >
