[
https://issues.apache.org/jira/browse/AMQ-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Boemker updated AMQ-4564:
-----------------------------
Description: When configured to use a secondary database for locking,
ActiveMQ creates and initializes ACTIVEMQ_LOCK in the primary database. It
then starts as slave because it can't lock the table in the secondary database.
(was: When configured to use a separate database for locking, ActiveMQ Cleanup
Timer notices that UPDATE ACTIVEMQ_LOCK SET TIME = ... WHERE ID = ... touches
no rows and stops the broker.
I noticed that there is a table named ACTIVEMQ_LOCK in the main database, and
that table has a row in it. When I copied that row to the instance of
ACTIVEMQ_LOCK in the database used for locking, ActiveMQ ran fine.
ActiveMQ apparently started to initialize ACTIVEMQ_LOCK before it realized that
it was supposed to use a separate data source for locking.
)
Summary: ActiveMQ creates & initializes ACTIVEMQ_LOCK in wrong database
when using separate lock data source (was: ActiveMQ fails to hold lock because
ACTIVEMQ_LOCK is missing a row)
> ActiveMQ creates & initializes ACTIVEMQ_LOCK in wrong database when using
> separate lock data source
> ---------------------------------------------------------------------------------------------------
>
> Key: AMQ-4564
> URL: https://issues.apache.org/jira/browse/AMQ-4564
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.5.1
> Reporter: Tim Boemker
> Priority: Minor
>
> When configured to use a secondary database for locking, ActiveMQ creates and
> initializes ACTIVEMQ_LOCK in the primary database. It then starts as slave
> because it can't lock the table in the secondary database.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
