2 Replies Latest reply on Oct 10, 2012 2:10 PM by Tom B-Oracle

    Configure independent JMS for multiple instances of same app?

      I am using WebLogic 10.3.5 within an Oracle Fusion Middleware 11g installation on linux.

      I want to set up multiple independent instances of an application that utilizes JMS. Each application should have its own queues and topics, i.e. they do not talk to each other. I am setting up separate servers for each application instance for ease of management. So I will have a Test server, a Training server, etc. within this installation of WebLogic.

      I am wondering what the best way to set up the JMS resources within WebLogic is. As I understand it, WebLogic has JMS servers, JMS modules and subdeployments. Do I need separate instances of each for each instance of the application, or could they share?
        • 1. Re: Configure independent JMS for multiple instances of same app?
          It looks like according to the documentation[1], the best thing to do is a separate JMS server - JMS module - subdeployment for each instance.

          [1] [http://docs.oracle.com/cd/E21764_01/web.1111/e13738/best_practice.htm#JMSAD455|http://docs.oracle.com/cd/E21764_01/web.1111/e13738/best_practice.htm#JMSAD455]
          • 2. Re: Configure independent JMS for multiple instances of same app?
            Tom B-Oracle

            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.