Embedded HornetQ with JMS-Bridge

[lostvicking]

Hi all,

I've an embedded instance of HornetQ in my application that I would like to bridge with Wildfly 8.2. The problem I've come up against is that I cannot get my hornetq-beans.xml to be picked up by my EmbeddedJms instance. In fact it seems that it will only recognise hornetq-configuration.xml and hornetq-jms.xml.

After reading the docs on embedding (Chapter 43. Embedding HornetQ) I think I understand that hornetq-beans.xml does not form part of the configuration file set for EmbeddedJms. So my question is whether it is possible to create such a bridge and if so, how can I do it? I did see some references made to the Jboss Microcontainer but I do not understand their significance.

Regards and thanks

Victor

[jbertram]

As you suspect, hornetq-beans.xml is not specifically a HornetQ configuration file which is why HornetQ doesn't recognize it.  The hornetq-beans.xml file is a JBoss Microcontainer configuration file and it's used to bootstrap the HornetQ POJOs.  If you want to bridge from your embedded HornetQ instance to HornetQ in Wildfly why not simply configure a "core" bridge in hornetq-configuration.xml?

[lostvicking]

Thank you Justin. I believe we will switch to using a standalone HornetQ instance instead. We tried going the core-bridge route but it seems to us that the JMS Bridge is more what we're after -- mainly because in the event of queue names not matching up on the local and remote side of the bridge we will see exceptions on start up. When using the core-bridge we saw that if the remote queue does not exist or has a different name the messages will disappear from the local queue and we need them to either be delivered to the remote queue or be returned to the local queue if there is anything wrong with the remote side.

[ataylor]

Justin is correct, you should use the core bridge, the JMS bridge is really just for transferring messages between different messaging vendors. The core bridge as developed to be fast and fault tolerant and will give you better guarantees than the JMS bridge. The core bridge has also been heavily tested to assure that there is no message loss. I dont really get your argument about the queue not existing as this is just configuration but saying that I don't really know your use case.

[lostvicking]

We want to be sure that in the event of mistakes in the config we will never lose a message. The thinking being that we cannot guarantee that the config will be correct (as it will not be done by developers in production but by admins) so we would like to guarantee that no message will ever be lost instead.

[ataylor]

so you are designing your whole application around the fact that admins may cock up , that seems a bit strange! why don't you just write an installer or some sort of initialization test to make sure this doesn't happen.

[jbertram]

I have to agree with Andy here.  It seems odd that you'd change your application design to deal with a potential configuration mistake.  Simply put, you can't account for all configuration mistakes, even many simple ones.

As an alternative, take a look at the <send-to-dla-on-no-route> setting.  It will ensure that if an address has no bindings then messages will be sent to the <dead-letter-address> rather than discarded.

One last thing...HornetQ's concept of address/queue routing and binding is very similar to the JMS concept of topic/subscriber.  If you sent a message to a JMS topic with no subscriber the message would be discarded.