[
https://issues.apache.org/jira/browse/AMQ-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772304#comment-13772304
]
Gary Tully commented on AMQ-4729:
---------------------------------
a workaround is described at:
https://issues.apache.org/jira/browse/AMQ-4365?focusedCommentId=13758262&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13758262
> mKahaDB master slave needs lock when filtered adapter locks are created on
> the fly
> ----------------------------------------------------------------------------------
>
> Key: AMQ-4729
> URL: https://issues.apache.org/jira/browse/AMQ-4729
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
> Affects Versions: 5.8.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Fix For: 5.9.0
>
>
> {code}<mKahaDB directory="../kahadb">
> <filteredPersistenceAdapters>
> <!-- kahaDB per destinations -->
> <filteredKahaDB perDestination="true" >
> <persistenceAdapter>
> <kahaDB journalMaxFileLength="32mb" />
> </persistenceAdapter>
> </filteredKahaDB>
> </filteredPersistenceAdapters>{code}
> problem:
> 1. Starting the slave with an "empty" database, i.e no queues results in the
> slave trying to start and ultimately failing as the address is in use.
> There's now lock. Pushing a message to TEST.FOO and then starting the
> database works OK. The slave comes up and locks and waits.
> 2. Now, adding a TEST.FOO1 to the master. The master now has the two queues,
> TEST.FOO and TEST.FOO1. Kill the master and let the slave take over. The
> slave only sees TEST.FOO. Not TEST.FOO1.
--
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
