activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher L. Shannon (JIRA)" <>
Subject [jira] [Reopened] (AMQ-5659) Add safety measure against infinite loop when store exception prevents message removal
Date Mon, 05 Dec 2016 12:32:58 GMT


Christopher L. Shannon reopened AMQ-5659:

I am reverting this patch as it has a major flaw.  The issue is that when purging messages
part of a transaction the message drop is done asynchronously so this patch won't work properly.
 This means that this patch will report an exception on purge when using a transaction because
because the counts stay the same for several iterations of the loop which is expected.  Take
a look at the removeMessage() method of the Queue class and you'll see that the messages aren't
dropped until after commit or rollback of the transaction.

In my opinion there needs to be a different solution here.  Arbitrarily picking some number
of times that the counts stay the same in a loop is not a good way to try and detect a failure
or infinite loop because things can happen async.

> 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
>            Assignee: Claus Ibsen
>             Fix For: 5.15.0
>         Attachments: purge_queue_abort_loop_v3.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