[jbertram]

1. What does this mean? And why did I ever successfully make the bridge work the first time withou this setting? I have never added this setting before.

It means that there is apparently some kind of problem (maybe a race condition) with the deployment order of core bridges and JMS destinations.  My inspection of the code indicates that this shouldn't be a problem, the JMS destinations should be deployed before core bridges, but clearly the problem exists.

My guess is that you either had persistence enabled or maybe once the race condition just didn't bit you (assuming it's a race).

2. I donot really undersand this comment: "you're not using persistence which forces the server to re-create all the core queues from scratch rather than just loading them from the bindings journal". Does that mean if the persistence is set to false, then the core queues do need to be mannually created by the core queues setting?

When persistence is enabled then HornetQ will persist queue bindings (whether those be "core" queues or JMS queues) to disk in the journal.  The first time the server starts after a new queue has been added to the XML obviously that queue isn't in the journal which means it has to be created "from scratch" and persisted to the journal.  However, once the queue binding is persisted the next time the server starts it can simply load it from the journal.  The timing of all this impacts your use-case.  For example, if you only define the JMS queues and if persistence is enabled the first time the server starts you'll receive a WARN and the bridge won't deploy.  However, the next time you start the server the queue binding will be in the journal and will be loaded more quickly so that the bridge will deploy successfully.  Manually specifying the core queue in the XML is just a way to work around this deployment timing issue because core queues are deployed before JMS queues.

But I am confused I have never head about this setting (core-queues) or read from hornetq user mannual doc. Does it only affect the bridge function? Because without it my project has been working fine on the jms function.

Core queues are a central part of HornetQ.  I'm not sure you could have missed that.  I even linked to this bit of documentation in a previous comment which explains the JMS-to-core mapping.  Perhaps you are confused that the configuration for core queues is somewhat different in JBossAS/Wildfly than it is for standalone HornetQ.

In any case, manually configuring the core queue only impacts this specific use-case.

[ohmygod]

Thanks for the detailed explanation.

Want to confirm with you again:

1. Did you mean that the timing issue is a hornetq's bug for now?

2. Can we walk around the timing issue by adding the bridge setting after the jms queues setting in the XML instead of mannually specifying the core queue?

3. If second answer is no, then do we still need to specify the core queue settings in the XML or not if setting the persistence to true?

[jbertram]

1. Did you mean that the timing issue is a hornetq's bug for now?

It's probably either a bug in HornetQ or in the messaging subsystem of JBossAS/Wildfly.

2. Can we walk around the timing issue by adding the bridge setting after the jms queues setting in the XML instead of mannually specifying the core queue?

I'm not sure what you mean by "after".  Are you talking about "after" chronologically or spatially in the file?

3. If second answer is no, then do we still need to specify the core queue settings in the XML or not if setting the persistence to true?

From my tests, if persistence is enabled then the bridge won't deploy the first time the server is started (i.e. when the bindings journal is empty).  However, every time you start the server after that the bridge should deploy fine.

[ohmygod]

Thanks for the answers.

The "after" means spatially in the file. Can this work?

If it can not work, then the timing issue can not be resolved unless mannually specifying the core queue for my case? Is that right?

[jbertram]

The "after" means spatially in the file. Can this work?

No, I don't think that would work.

If it can not work, then the timing issue can not be resolved unless mannually specifying the core queue for my case? Is that right?

Correct.

[ohmygod]

I am closing this thread now. I will open new thread if I meet with more issues.Thanks so much again for all your help here.