Destinations created through the management console or management API are stored on the bindings folder. (the jms journal). If you use shared or replicated journal, all the destinations created at the live will be placed on the backup.
For manual configuration however, you would have to copy the files manually and keep them in sync.
Wold that be an issue for you guys?
Thank you for your response.
I guess this leads me to more questions. What is the preferred approach to creating destinations? I see multiple options:
(a) Use the API (management API and/or JMX)
(b) Manually edit the hornetq-jms.xml file and keep the file in sync on the active and backup node.
(c) Manually edit the hornetq-jms.xml file and keep it on the shared store.
(b) is a poor solution. The risk of missing an update is high. (a) and (c) are reasonable, however I dont see how one could not end up with some destinations defined in the hornetq-jms.xml file and some destinations in the bindings/journal folder. This would be really confusing at the minimum.
What about JON? Would we be able to add destiations using JON, and if so, where would these get stored?
Also what about user records. Are there any API's to create users remotely? Or would it just be best to just manually edit the hornetq-users.xml file and keep it on the shared drive?
JON will use the API, those destinations are stored on the journal.
It looks like you can either choose the replicated journal, the shared folder on the configuration... or a mix of both.
From our Point of View (hornetQ) security is pluggable through JAAS. We just call the authentication method at JAAS and we expect the users are already there.
I will ask Anil Saldanha (Security Lead) to answer this thread.
You could also ask in the support portal, as they have a wider view of the other products. (I know you guys are also customers).
Ideally, the cluster nodes are expected to be homegeneous and smaller in number. So you have to maintain the same configuration on each node in a cluster.
My conclusions are that for the hornetq-users.xml file, the only options are either to manually keep both copies of the file in sync, or to put the file on the share, and then add that specific share directory to the hornetQ classpath. Are there any concerns with putting the hornetq-users.xml file on the share?
For jms objects,it just seems like asking for trouble when we have jms objects defined in two different places depending on how you added them. I would think that given the current design, its best to only use the API to add JMS objects (queues, topics, connection factories) and to not use the hornetq-jms.xml file at all.
Comments? Other suggestions?
If the queues are defined at development time.. I would put them on hornetq-jms.
I would actually place it on your application archive (if you have one). If you are using JBoss 6 or the next EAP version, you can have any file named as *-hornetq-jms.xml and have it deployed to your EAR. This way your application would be always in sync with the production environment.
If the queues are defined during runtime.. (I.e. your application is creating the queues based on some meta-data), then you use the api and keep them in the journal.
that's my suggestion. But it all depends on how your application is deployed / developed.
I'm using JBoss 6 M4 and have tried puting crp-hornetq-jms.xml file in the ROOT of my EAR (crp beeing project name, tried also simple hornetq-jms.xml).
The file looks like this:
<configuration xmlns="urn:hornetq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd"> <queue name="testQueue"> <entry name="/queue/testQueue"/> </queue> </configuration>
yet the queue does not get deployed.
Do i have to put it in some jboss-app.xml or similar so it's picked up by hornetq ?
When I put this queue in server/default/deploy/hornetq/hornetq-jms.xml it works like charm.