[
https://issues.apache.org/jira/browse/AMQ-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16776886#comment-16776886
]
Gary Tully commented on AMQ-7154:
---------------------------------
[~cshannon] this is interesting, is this a preexisting inversion problem or
related to the DLQ expiry looping back to the DLQ.
If it is just DLQ expiry - then disabling periodic Expiry via a policy entry
for the DLQ would workaround, or having a separate DLQ for DLQ expired messages
etc.
Send to the DLQ caused problems with the index lock before, when duplicates
are detected, queing up and processing outside the lock was the best solution I
could come up with at that time.
see the usage of duplicatesFromStore -
https://github.com/apache/activemq/blob/bcad7e1f6a6dd078d87787a03b56560e995ef773/activemq-broker/src/main/java/org/apache/activemq/broker/region/BaseDestination.java#L874
In general, taking the expiry processing out of the pageInloop is the way to
go, having a limit on the amount do queue would also be beneficial for periodic
expiry.
Some combination of the regionbroker stampAsExpired or the message reference
isExpired can ensure expiry is idempotent.
> Broker Deadlock while processing expired DLQ messages
> -----------------------------------------------------
>
> Key: AMQ-7154
> URL: https://issues.apache.org/jira/browse/AMQ-7154
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.12.0
> Reporter: Kestutis Gedminas
> Priority: Major
> Attachments: amq.svg, threaddump.zip
>
>
> We get a deadlock on AMQ. After analysis, it looks like in case if expired
> messages thread is processing DLQ queue at the same moment when poisonAck is
> received we run into preexisting racing condition in code due to inconsistent
> lock acquiring order.
> [ !amq.svg|width=1000!|^amq.svg]
>
> [^threaddump.zip]
> [^amq.svg]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
