EAP 6.3.3 HornetQ Bridges don't work on clean JBoss, no queue found with name X

[japearson]

Hi,

I have a problem with the embedded HornetQ 2.3.21.Final running inside JBoss EAP 6.3.3

I have found that when running on a clean JBoss, ie delete standalone/{tmp,work,data}, the HornetQ bridges don't work because the JMS queues don't exist yet.  It seems that the first time JBoss is started it tries to configure the Bridges before creating queues.

I have taken these excerpts from the server.log, and you can see the timing seems to be deploy bridges and then deploy queues.

13:34:41,550 WARN  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ222125: No queue found with name jms.queue.event.forward.Misc bridge miscBridge will not be deployed.

13:34:42,297 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 63) HQ221003: trying to deploy queue jms.queue.event.forward.Misc

13:34:42,308 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 63) JBAS011601: Bound messaging object to jndi name java:/queue/event.forward.Misc

Now if I delete the bridges using the cli, and then create them again, the bridges come up fine on subsequent restarts.  But if I delete tmp, work, data, then it's broken until I recreate them through the CLI.

Is this expected behavour? It seems odd that you can't have a working bridge from a standalone.xml that has everything configured already.

Here is the relevant snippets from the standalone.xml:

                    <bridge name="miscBridge">

                        <queue-name>jms.queue.event.forward.Misc</queue-name>

                        <forwarding-address>jms.queue.event.group.Misc</forwarding-address>

                        <min-large-message-size>102400</min-large-message-size>

                        <check-period>30000</check-period>

                        <connection-ttl>60000</connection-ttl>

                        <retry-interval>2000</retry-interval>

                        <retry-interval-multiplier>1.5</retry-interval-multiplier>

                        <max-retry-interval>10000</max-retry-interval>

                        <reconnect-attempts>-1</reconnect-attempts>

                        <failover-on-server-shutdown>false</failover-on-server-shutdown>

                        <confirmation-window-size>1048576</confirmation-window-size>

                        <static-connectors>

                            <connector-ref>

                                remoteMiscConnector

                            </connector-ref>

                        </static-connectors>

                    </bridge>

                    <connector name="remoteMiscConnector" socket-binding="messaging-t

hroughput">

                        <factory-class>org.hornetq.core.remoting.impl.netty.NettyConn

ectorFactory</factory-class>

                        <param key="host" value="localhost"/>

                        <param key="port" value="5455}"/

>

                    </connector>

                    <jms-queue name="event.forward.Misc">

                        <entry name="queue/event.forward.Misc"/>

                    </jms-queue>

[jbertram]

Is this expected behavour?

Yes.

A core bridge works on core resources.  At the time the core bridge is deployed the JMS queues (and the core queues that back them) have not yet been deployed.  If you want this use-case to work then you should create specify the appropriate core queue in your XML configuration so it is deployed before the core bridge.

[japearson]

Right thanks, I needed to create it using the CLI and I found could create a core queue as the same name as the JMS queue, and it made all my problems go away.

/subsystem=messaging/hornetq-server=default/queue=jms.queue.event.forward.Misc/:add(queue-address=jms.queue.event.forward.Misc)

Is there anything wrong with not using separate names between the core queue and jms queue?

[jbertram]

Is there anything wrong with not using separate names between the core queue and jms queue?

No.  In short, a JMS queue is just a core queue whose name is prefixed with "jms.queue."  The only benefit you get from defining a JMS queue explicitly is the ability to specify JNDI entries.  You can read more about the core-to-JMS mapping here.

[japearson]

I decided to name them separately in the end, because I was getting NullPointerException's in my CLI batch file sometimes when creating the core queues, jms queues and bridges.

Naming the core queues differently to the jms queues worked around that issue.

Initially I found that if I created the Core Queues higher up in the CLI batch file it would work, but it was unreliable.

[isurul]

To add a core queue in standalone.xml configuration

<core-queues>    

  <queue name="jms.queue.FromQueue">

     <address>jms.queue.FromQueue</address>

     <durable>true</durable>

  </queue>

</core-queues>