This content has been marked as final. Show 2 replies
It looks like according to the documentation, the best thing to do is a separate JMS server - JMS module - subdeployment for each instance.
Subdeployments are highly recommended for destination configuration as a best practice:
The following might help:
* A WL domain can host multiple individual WL servers and/or clusters of WL servers.
* A WL cluster, or even a single WL server, can host one or more sets of JMS servers.
* Each WL JMS server instance in a set is configured and targeted individually. A logical JMS server consisting of a set of JMS servers is comprised of multiple configured JMS server instances.
* Each set of JMS servers can in turn host independent clustered destinations from one or more modules. For example, you can configure a "uniform distributed queue" in a module, and target the distributed queue by having it reference a subdeployment for the module that in turn references each JMS server in a particular set a of JMS servers.
* (BTW, for 12.1.2 we're planning on delivering a feature that eliminates the need to configure each JMS server in a set individually.)
* You can configure security (ACLs) at the per-module level, or the fine grained per-destination level.
* The configured "mbean" names of two different destinations can be the same in different modules, but their JNDI names must be different. This is because the JNDI name-space is shared across the entire cluster.