Description of problem: Test scenario: 1. Start 2 EAP 6.x servers in collocated HA topology with shared journal 2. Kill 2nd server -> failover occurs 3. Start 2nd server -> failback occurs Result: Queues/Topics are unbound from JNDI on 1st server. During Failback the HQ backup on 1st server is shutdowned and this unbounds destinations from JNDI. Problem is that there is still HQ live running which do not have queues/topics in JNDI on 1st server. Same queues/topics were defined in configuration for live and also for backup (on 1st server). If queues/topics are removed from configuration of HQ backup then after failback are all queues/topics still in JNDI. Expected results: We can discuss what we can do in this case. My suggestions are: 1. option: Document this behavior - "Do not configure destinations in collocated backup..." 2. Improve integration for collocated backup. It'd detect live server and does not undeploy destinations "shared" destination. Or print warning during start of the server. I'm not sure if it's possible. I guess the same behavior is for deployed connection factories but I did not try it.
There is still the same problem in EAP 6.3.0.DR4. (HQ 2.3.18.Final).
Your first comment states, "Same queues/topics were defined in configuration for live and also for backup (on 1st server)." As far as I can tell, this is a simple misconfiguration. You should not, in fact, configure any JNDI resources on the colocated backup. It should only have the very basic configuration elements it needs to start as exemplified by the <JBOSS_HOME>/docs/examples/configs/standalone-hornetq-colocated.xml shipped with JBoss EAP. As you suggest, the JBoss EAP documentation should be adjusted to reflect this. In the future we are doing to simplify the declaration of a backup server so this whole configuration process is simpler.
Hi Justin, thanks for feedback. I just don't want to loose focus from this bz as it appears to be not intuitive. For dedicated backup we have to specify destinations in its configuration but for colocated backup we cannot. Doc will be fine, improvement great. I'll create new bz to document this and keep this open for tracking progress. Thanks, Mirek