activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (AMQ-5659) Add safety measure against infinite loop when store exception prevents message removal
Date Thu, 12 Mar 2015 15:54:38 GMT


ASF GitHub Bot commented on AMQ-5659:

GitHub user metatechbe opened a pull request:

    AMQ-5659 Safety measure against infinite loop in "purge" (V2)


You can merge this pull request into a Git repository by running:

    $ git pull patch-3

Alternatively you can review and apply these changes as the patch at:

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 <>
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:
>             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
> {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(
> 	at org.apache.commons.dbcp.BasicDataSource.getConnection(
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at$1.removeAsyncMessage(
> 	at
> 	at
> 	at
> 	at
> 	at
> 	at
> {code}

This message was sent by Atlassian JIRA

View raw message