[
https://issues.apache.org/jira/browse/AMQ-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358859#comment-14358859
]
ASF GitHub Bot commented on AMQ-5659:
-------------------------------------
GitHub user metatechbe opened a pull request:
https://github.com/apache/activemq/pull/72
AMQ-5659 Safety measure against infinite loop in "purge" (V2)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/metatechbe/activemq patch-3
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq/pull/72.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #72
----
commit 825b7bb72f635138d6578f9c19db88ac7ca77fcf
Author: metatechbe <[email protected]>
Date: 2015-03-12T15:53:30Z
AMQ-5659 Safety measure against infinite loop in "purge" (V2)
----
> Add safety measure against infinite loop when store exception prevents
> message removal
> --------------------------------------------------------------------------------------
>
> Key: AMQ-5659
> URL: https://issues.apache.org/jira/browse/AMQ-5659
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.7.0
> Environment: ServiceMix 4.5.3
> Reporter: metatech
> Attachments: purge_queue_abort_loop.patch,
> purge_queue_abort_loop_v2.patch
>
>
> When the broker is configured with a database store, the "purge" operation
> enters an infinite loop when the message removal operation fails, for
> instance when the broker datasource is being restarted (see example stack
> trace below).
> Here is a patch which adds a safety measure, in case the "dequeue" count of
> the queue does not increase between 2 messages removal operations. The check
> is not garanteed to detect the problem on the next iteration, because a
> business consumer might also be dequeuing messages from the queue. But the
> "purge" is probably much faster than the business consumer, so if it fails to
> remove 2 messages in a row, it is enough to detect the problem and abort the
> infinite loop.
> {code}
> 2015-03-05 15:38:30,353 | WARN | 14571659-2202099 | |
> JDBCPersistenceAdapter | Could not get JDBC connection: Data source
> is closed
> java.sql.SQLException: Data source is closed
> at
> org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1362)
> at
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
> at
> org.apache.activemq.store.jdbc.TransactionContext.getConnection(TransactionContext.java:58)
> at
> org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.getStoreSequenceId(DefaultJDBCAdapter.java:285)
> at
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getStoreSequenceIdForMessageId(JDBCPersistenceAdapter.java:787)
> at
> org.apache.activemq.store.jdbc.JDBCMessageStore.removeMessage(JDBCMessageStore.java:194)
> at
> org.apache.activemq.store.memory.MemoryTransactionStore.removeMessage(MemoryTransactionStore.java:358)
> at
> org.apache.activemq.store.memory.MemoryTransactionStore$1.removeAsyncMessage(MemoryTransactionStore.java:166)
> at org.apache.activemq.broker.region.Queue.acknowledge(Queue.java:846)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1602)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1594)
> at
> org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1579)
> at org.apache.activemq.broker.region.Queue.purge(Queue.java:1158)
> at org.apache.activemq.broker.jmx.QueueView.purge(QueueView.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
