11 Replies Latest reply: Jul 17, 2012 8:22 AM by Chris Lott RSS

Remote JMS queue in JBoss AS 7.1

Devasis Bassu Newbie

Hi,

 

Am having some trouble setting up the following scenario - I have two JBoss AS 7.1 servers X and Y (not clustered). X defines a JMS queue and I want Y to use it as a remote queue. I setup a netty-connector in domain.xml for Y pointing back to X - however, I get failed to login messages from the AS (hornetq) when I try to bring up Y. Eventually, I'll have multiple JBoss AS servers listening to the same remote queue.

 

Any pointers to documentation or help would be appreciated.

Thanks,

Devasis

  • 1. Re: Remote JMS queue in JBoss AS 7.1
    tc7 Newbie

    Devasis, I too have been trying to work out how to configure JMS - as the arrival of JBoss-7.1.0.Final (secured by default) highlighted my lack of understanding in this area! I have successfully configured a remote queue (topic) for server notifications (via message driven beans), but the configuration principles should apply for any remote queue.

     

    We have a similar requirement to that outlined above i.e. two JBoss 7.1 server instances X and Y (not clustered). We have successfully configured hornetq-ra with a remote queue.

    In development the remote queue points to local-host, but still uses the same outbound connector.

     

    Key concepts I was unfamiliar with are:

    1) consumer connections need to be started, producer connections do not

    2) connection factories are always looked up with JNDI, and are required in order to create a connection/session for either sending / receiving messages

    3) destination queue/topic can be looked up in one of two ways:

      a) via the JMS API using connection.createQueue(..) or connection.createTopic(..)

      b) via JNDI

      From my limited research it appears option a) is more efficient - this approach also makes logical sense i.e. to minimise JNDI lookups where possible.

    4) there are various ways to supply credentials - which are required when accessing remote destinations

     

    The above are illustrated below.

     

    A) JMS queue/topic configuration

     

    Here's the important parts of our hornetq configuration (using standalone-full.xml as the starting point):

    <hornetq-server>

        <persistence-enabled>true</persistence-enabled>

        <!-- Default journal file size is 10Mb, reduced here to 100k for faster first boot -->

        <journal-file-size>102400</journal-file-size>

        <journal-min-files>2</journal-min-files>

     

        <connectors>

            <netty-connector name="netty" socket-binding="messaging"/>

            <netty-connector name="netty-throughput" socket-binding="messaging-throughput">

                <param key="batch-delay" value="50"/>

            </netty-connector>

            <in-vm-connector name="in-vm" server-id="0"/>

            <!-- server notification connector -->

           <netty-connector name="server-notification-connector" socket-binding="server-notification-socket-binding" />

        </connectors>

        ...

     

        <jms-connection-factories>

            <connection-factory name="InVmConnectionFactory">

                <connectors>

                    <connector-ref connector-name="in-vm"/>

                </connectors>

                <entries>

                    <entry name="java:/ConnectionFactory"/>

                </entries>

            </connection-factory>

            <connection-factory name="RemoteConnectionFactory">

                <connectors>

                    <connector-ref connector-name="netty"/>

                </connectors>

                <entries>

                    <entry name="RemoteConnectionFactory"/>

                    <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>

                </entries>

            </connection-factory>

     

            <!--<pooled-connection-factory name="hornetq-ra">

                <transaction mode="xa"/>

                <connectors>

                    <connector-ref connector-name="in-vm"/>

                </connectors>

                <entries>

                    <entry name="java:/JmsXA"/>

                </entries>

            </pooled-connection-factory>-->

     

            <pooled-connection-factory name="hornetq-ra">

                <transaction mode="xa"/>

                <connectors>

                    <connector-ref connector-name="server-notification-connector"/>

                </connectors>

                <entries>

                    <entry name="java:/JmsXA"/>

                </entries>

            </pooled-connection-factory>

            <!-- the following are obliterated on server shutdown - see not on JBoss Security below -->

            <user>jmsUser</user>

            <password>password</password>

        </jms-connection-factories>

     

        <jms-destinations>   

            ...

            <!-- use for publish / subscribe -->

            <jms-topic name="ServerNotificationTopic">

                <entry name="java:jboss/exported/jms/topic/ServerNotification"/>

            </jms-topic>

        </jms-destinations>

    </hornetq-server>

    ...

     

    <outbound-socket-binding name="server-notification-socket-binding">

        <!-- DEV (local) -->

        <remote-destination host="localhost" port="5445"/>

    </outbound-socket-binding>

     

    The key here of course is to:

    a) link connection factory to the connector

    b) connector to the appropriate socket binding

    c) point the socket binding to the appropriate host/port where the remote queue/topic is available

     

    JBoss security

    Unfortunately I came across the following anomaly with the <pooled-connection-factory> configuration above.

    The <username> and <password> elements are clobbered on normal jboss shutdown. In other words it works once, then <username> and <password> elements must be added again in preparation for the next application server boot!

     

    The following workaround should suffice until the above is addressed:

    <security-domain name="other" cache-type="default">

        <authentication>

            <login-module code="Remoting" flag="optional">

                <module-option name="password-stacking" value="useFirstPass"/>

            </login-module>

            <login-module code="RealmUsersRoles" flag="required">

                <module-option name="usersProperties" value="${jboss.server.config.dir}/application-users.properties"/>

                <module-option name="rolesProperties" value="${jboss.server.config.dir}/application-roles.properties"/>

                <module-option name="realm" value="ApplicationRealm"/>

                <module-option name="password-stacking" value="useFirstPass"/>

                <module-option name="unauthenticatedIdentity" value="guest"/>

            </login-module>

        </authentication>

    </security-domain>

     

    B) How to lookup the connection factory

    InitialContext context = new InitialContext();

     

    // 1) lookup connection factory (local JNDI lookup, no credentials required)

    javax.jms.ConnectionFactory cf = (javax.jms.ConnectionFactory)context.lookup("JmsXA");

     

    // 2) create a connection to the remote provider

    javax.jms.Connection c = cf.createConnection("jmsUser", "password");

     

    It's important in step 2) above that you use the username and password of an account created on the destination JBoss instance.

    bin/add-user.sh

    application user, realm: ApplicationRealm, username: "jmsUser", password: "password", roles: guest

     

    C) How to send messages on the queue/topic

    steps 1 and 2 above, then:

     

    // 3) create session session

    boolean transacted = false;

    javax.jms.Session session = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE);

     

    // 4) "create" the queue/topic (using the topic name - not JNDI)

    javax.jms.Topic topic = session.createTopic("ServerNotificationTopic");

     

    // 5) create message

    TextMessage textMessage = session.createTextMessage();

    textMessage.setText("hello");

    // textMessage.setObjectProperty("MySelector", "MyHandlerValue");

     

    // 6) create producer

    javax.jms.MessageProducer producer = session.createProducer(topic);

     

    // 7) send message

    producer.send(textMessage);

     

    D) How to listen for messages on the queue/topic

    steps 1 and 2 above, then:

     

    // 3) create session session

    boolean transacted = false;

    javax.jms.Session session = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE);

     

    // 4) "create" the queue/topic (using the topic name - not JNDI)

    javax.jms.Topic topic = session.createTopic("ServerNotificationTopic");

     

    // 5) create consumer

    javax.jms.MessageConsumer consumer = session.createConsumer(topic); // messageSelector is optional

     

    // 6) set listener

    consumer.setMessageListener(new javax.jms.MessageListener() {

      public void onMessage(javax.jms.Message message)

      {

        System.out.println("received message: "+message);

      }

    });

     

    // 7) listen for messages (start the connection)

    c.start();

     

    E) Alternative queue lookup using JNDI

    There is an alternative to the JMS api queue/topic "creation" illustrated above. However I can't see the benefit of:

    a) looking up the connection factory via JNDI, and then

    b) looking up the queue via JNDI when it's available via the jms session, and the session is need to either send or receive a message.

     

    The lookup seems to require credentials in the following form, eg:

    InitialContext context = new InitialContext();

    context.addToEnvironment("InitialContext.PROVIDER_URL", "remote://localhost:4447");

    context.addToEnvironment("InitialContext.SECURITY_PRINCIPAL", "jmsUser");

    context.addToEnvironment("InitialContext.SECURITY_CREDENTIALS", "password");

    context.addToEnvironment("InitialContext.SECURITY_AUTHENTICATION", "simple");

    javax.jms.Topic topic = (javax.jms.Topic)context.lookup("jboss/exported/jms/topic/ServerNotification");

     

    the above topic could then be substituted into either of the above (C or D).

     

    F) Message Driven Bean

    This is essentially a combination of  D) and E) above but using annotations.

    Once again the JNDI destination is used (rather than the jms topic name), eg:

    jndi name: jboss/exported/jms/topic/ServerNotification

     

    @MessageDriven(

        name = "MyMdbHandlerName",

        activationConfig = {

            @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),

            @ActivationConfigProperty(propertyName = "destination", propertyValue = "jboss/exported/jms/topic/ServerNotification"),

            //@ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "MySelector='MyHandlerValue'"),

            @ActivationConfigProperty(propertyName = "user", propertyValue = "jmsUser"),

            @ActivationConfigProperty(propertyName = "password", propertyValue = "password"),

            @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge")

        })

    public class MyMdbHandler implements javax.jms.MessageListener

    {

        public void onMessage(javax.jms.Message message)

        {

        System.out.println("received message: "+message);

        }

    }

     

    In reality its much more useful to use a message selector (commented above), but I've mostly left this out to avoid confusion.

    Once again credentials are key to getting this working - and making sure appropriate users have been created at the application server level.

     

    Let me know if the above helps you through!

     

    regards,

    tc

     

     

    References

        1) Remote JMS client with JBoss https://community.jboss.org/thread/173066

        2) Queue from JMS api vs JNDI https://community.jboss.org/thread/174708

        3) Connect from inside/outside JBoss app server https://community.jboss.org/thread/195845

        4) unauthenticated identity https://community.jboss.org/message/719946#719946

  • 2. Re: Remote JMS queue in JBoss AS 7.1
    Justin Bertram Master

    A few points/corrections...

    1) consumer connections need to be started, producer connections do not

    That's correct.  This is documented in the JMS JavaDoc (since "incoming messages" don't make sense for a producer).

    2) connection factories are always looked up with JNDI, and are required in order to create a connection/session for either sending / receiving messages

    To be clear, the use of JNDI is a convention established by JMS 1.1 spec, but not a strict requirement.  See section 4.2 of the spec:

    Although the interfaces for administered objects do not explicitly depend on JNDI,

    JMS establishes the convention that JMS clients find them by looking them up in a

    namespace using JNDI.

    JBoss AS 7.1.0.Final currently follows this convention for JMS clients, but this can be circumvented by using the HornetQ API directly.

    3) destination queue/topic can be looked up in one of two ways:

      a) via the JMS API using connection.createQueue(..) or connection.createTopic(..)

      b) via JNDI

    To be clear, option '3a' is not a look-up per se.  It is creating a queue identity, not looking up a reference to the queue.

     

    Also, the createQueue(..) and createTopic(..) methods are not on javax.jms.Connection.  They are on javax.jms.Session.

    4) there are various ways to supply credentials - which are required when accessing remote destinations

    From a JMS API perspective the only way to pass credentials is via javax.jms.ConnectionFactory.createConnection(String username, String password) (or the XA equivalent).

        <connectors>

            <netty-connector name="netty" socket-binding="messaging"/>

            <netty-connector name="netty-throughput" socket-binding="messaging-throughput">

                <param key="batch-delay" value="50"/>

            </netty-connector>

            <in-vm-connector name="in-vm" server-id="0"/>

            <!-- server notification connector -->

           <netty-connector name="server-notification-connector" socket-binding="server-notification-socket-binding" />

        </connectors>

        ...

     

    <outbound-socket-binding name="server-notification-socket-binding">

        <!-- DEV (local) -->

        <remote-destination host="localhost" port="5445"/>

    </outbound-socket-binding>

     

    You can accomplish the same thing using this kind of connector (which requires no socket binding):

     

       <connector name="remote-jmsxa">

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

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

          <param key="port" value="5445"/>

       </connector>

    D) How to listen for messages on the queue/topic

    To be clear, the JmsXA connection factory uses the HornetQ JCA outbound adapter which should be used for sending messages.  To consume messages in a Java EE context you should use an MDB which uses the HornetQ JCA inbound adapter.  If you don't want to use an MDB to consume messages then you should use the RemoteConnectionFactory from the remote server.

    The lookup seems to require credentials in the following form, eg:

    InitialContext context = new InitialContext();

    context.addToEnvironment("InitialContext.PROVIDER_URL", "remote://localhost:4447");

    context.addToEnvironment("InitialContext.SECURITY_PRINCIPAL", "jmsUser");

    context.addToEnvironment("InitialContext.SECURITY_CREDENTIALS", "password");

    context.addToEnvironment("InitialContext.SECURITY_AUTHENTICATION", "simple");

    javax.jms.Topic topic = (javax.jms.Topic)context.lookup("jboss/exported/jms/topic/ServerNotification");

    From a remote client I recommend this basic lookup (notice the addition of INITIAL_CONTEXT_FACTORY and removal of SECURITY_AUTHENTICATION as well as a simpler lookup string):

     

            final Properties env = new Properties();

            env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

            env.put(Context.PROVIDER_URL, "remote://localhost:4447");

            env.put(Context.SECURITY_PRINCIPAL, "guest");

            env.put(Context.SECURITY_CREDENTIALS, "pass");

            Context context = new InitialContext(env);

            ConnectionFactory cf = (ConnectionFactory) context.lookup("jms/RemoteConnectionFactory");

            Destination destination = (Destination) context.lookup("jms/queue/test"); // only necessary if you don't want to use createQueue or createTopic

     

    F) Message Driven Bean

    Is your MDB supposed to be consuming messages from a remote destination?  If so, where is the activation configuration properties to tell it where to find the remote server?

  • 3. Re: Remote JMS queue in JBoss AS 7.1
    tc7 Newbie

    Thanks for the reply Justin - it's always good to know there are people out there listening!

    I must confess its taken longer than expected to get across all this - I probably should have put a bit more effort in from the outset.

    However there seems to be plenty of confusion out there - so perhaps I'm not alone. It would be great to have more detail added to the JMS doc page written for 7.1 ...

     

    In response to your response re "key concepts"...

    Q1-3) point taken.

    Q4) I was trying to illustrate the various places in which credentials may be required (since 7.1.0.Final), and the distinction between jms api security (user/password) and jndi security (provider/principal/credentials/authentication).

      a) standalone-full.xml --> pooled-connection-factory (user/password) <-- these do not persist after the first server restart

      b) connection factory lookup via jndi (provider/principal/credentials/authentication)

      c) queue lookup vi jndi (provider/principal/credentials/authentication)

      d) java annotations (e.g. Message Driven Bean) (user/password)

      e) jms api (user/password)

    It seems only lookups for remote items require credentials.

     

    D) I misunderstood the meaning of "outbound", probably as I couldn't otherwise see a way of providing host/port to a socket binding. I'll use your connector config - I assume that is suitable for both message producers and consumers?

    F) I assume you mean the connectionFactoryJndiName!?

     

    Here's what I now have:

    1) remote connector

    I've defined a single connector for access to the connection factory / queues on the remote server (thanks Justin):

                <connector name="remote-jms">

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

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

                    <param key="port" value="5445"/>

                </connector>

     

    2) connection factories

    I've defined two connection factories that use this remote connector:

        <connection-factory name="RemoteConnectionFactory">

            <connectors>

                <connector-ref connector-name="remote-jms"/>

            </connectors>

            <entries>

                <entry name="java:/RemoteConnectionFactory"/>

                <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>

            </entries>

        </connection-factory>Thanks for the reply Justin - it's always good to know there are people out there listening!

     

    and (in case I want a pooled connection factory)

        <pooled-connection-factory name="hornetq-ra">

            <transaction mode="xa"/>

            <connectors>

                <connector-ref connector-name="remote-jms"/>

            </connectors>

            <entries>

                <entry name="java:/remote-JmsXA"/>

            </entries>

        </pooled-connection-factory>

     

    3) modified MDB activation config (added connectionFactoryJndiName)

    @MessageDriven(

        name = "MyMdbHandlerName",

        activationConfig = {

            @ActivationConfigProperty(propertyName = "connectionFactoryJndiName", propertyValue = "RemoteConnectionFactory"),

            @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),

            @ActivationConfigProperty(propertyName = "destination", propertyValue = "topic/ServerNotification"),

            //@ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "MySelector='MyHandlerValue'"),

            @ActivationConfigProperty(propertyName = "user", propertyValue = "jmsUser"),

            @ActivationConfigProperty(propertyName = "password", propertyValue = "password"),

            @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge")

        })

    public class MyMdbHandler implements javax.jms.MessageListener

    {

        public void onMessage(javax.jms.Message message)

        {

        System.out.println("received message: "+message);

        }

    }

    For now I'm using the standard RemoteConnectionFactory - I'll see how this goes.

     

    4) simplified topic name

        <!-- use for publish / subscribe -->

        <jms-topic name="ServerNotificationTopic">

            <entry name="topic/ServerNotification"/>

            <entry name="java:jboss/exported/jms/topic/ServerNotification"/>

        </jms-topic>

     

     

    It appears to work fine both locally in "dev mode" (using localhost as the "remote" host), and with a real remote server.

    I've avoided using an MDB descriptor - and am happy to be able to modify the configuration for different environments via standalone-full.xml (and without modifying our code base or bundled configuration files).

     

    Please let me know if I've still missed the mark, or if this looks better.

     

    cheers,

    tc

  • 4. Re: Remote JMS queue in JBoss AS 7.1
    Justin Bertram Master

    Sorry for taking so long to follow-up on this.  It dropped off my radar.

     

    Let's begin here:

    D) I misunderstood the meaning of "outbound", probably as I couldn't otherwise see a way of providing host/port to a socket binding. I'll use your connector config - I assume that is suitable for both message producers and consumers?

    As I stated in my previous comment, connection factories like "JmsXA" (i.e. <pooled-connection-factory>) should only be used to send messages, not consume them.  To consume messages in a Java EE context you should use an MDB which uses the HornetQ JCA inbound adapter.

    F) I assume you mean the connectionFactoryJndiName!?

    I'm not familiar with "connectionFactoryJndiName."  I don't see any mention of it in the HornetQ docs or the code-base.  Can you clarify what "connectionFactoryJndiName" is?

     

    In my previous comment when I asked how the MDB knew where to connect to consume the messages from the remote topic I had in mind a configuration similar to this:

     

    @MessageDriven(name = "myMDB", activationConfig = { 
            @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
            @ActivationConfigProperty(propertyName = "destination", propertyValue = "testQueue"),
            @ActivationConfigProperty(propertyName = "connectorClassName", propertyValue = "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"),        
            @ActivationConfigProperty(propertyName = "connectionParameters", propertyValue = "host=remoteHost;port=5445")})
    

     

    Here the MDB is configured to consume messages from "testQueue" which resides on remoteHost:5445.  Note, this has nothing to do with any <connection-factory> or <pooled-connection-factory> because the MDBs configuration is 100% independent of those artifacts. 

     

    Remember, in a Java EE context it is recommended to consume messages with an MDB (which uses the inbound JCA adapter) and to produce/send messages with a <pooled-connection-factory> (which uses the outbound JCA adapter).  This has been the same, basic recommendation for years in JBoss AS, and the recommendation holds whether the messages are local or remote.

        <connection-factory name="RemoteConnectionFactory">

            <connectors>

                <connector-ref connector-name="remote-jms"/>

            </connectors>

            <entries>

                <entry name="java:/RemoteConnectionFactory"/>

                <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>

            </entries>

        </connection-factory>

    We've discussed this kind of configuration in private, but I wanted to make a note of it here for posterity's sake.  I believe you are under the impression that this is the appropriate way to get a connection to a remote server, but it is not.  The "RemoteConnectionFactory" exists so that clients which are remote from the local server (e.g. standalone JMS clients running a Java SE context) can connect to it.  Let me know if you have any lingering questions here.  Also, take a look at this thread for futher details about connectors and connection factories.

    3) modified MDB activation config (added connectionFactoryJndiName)

    @MessageDriven(

        name = "MyMdbHandlerName",

        activationConfig = {

            @ActivationConfigProperty(propertyName = "connectionFactoryJndiName", propertyValue = "RemoteConnectionFactory"),

            @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),

            @ActivationConfigProperty(propertyName = "destination", propertyValue = "topic/ServerNotification"),

            //@ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "MySelector='MyHandlerValue'"),

            @ActivationConfigProperty(propertyName = "user", propertyValue = "jmsUser"),

            @ActivationConfigProperty(propertyName = "password", propertyValue = "password"),

            @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge")

        })

    public class MyMdbHandler implements javax.jms.MessageListener

    {

        public void onMessage(javax.jms.Message message)

        {

        System.out.println("received message: "+message);

        }

    }

    As I mentioned before, I'm not familiar with the "connectionFactoryJndiName" activation configuration property.  I don't see how this could actually connect to a remote server and consume messages.  See my example regarding how to tell and MDB to connect to a remote server.

  • 5. Re: Remote JMS queue in JBoss AS 7.1
    Justin Bertram Master

    FYI - I updated the documentation to hopefully shed more light on the JMS connection factories available in AS7.

  • 6. Re: Remote JMS queue in JBoss AS 7.1
    Luiz Carlos Silva Newbie

    Hi friends,

    I need to do a similar setup and I was doing the steps described above. I have two server where the first utility JBoss 7 and the secund is one JMS Server HornetQ, but

    I am having trouble connecting. My Listener not is call.

  • 7. Re: Remote JMS queue in JBoss AS 7.1
    Justin Bertram Master

    Please open a new thread regarding your issue and describe your environment in more detail as well as the specific error/behavior you are seeing.

  • 8. Re: Remote JMS queue in JBoss AS 7.1
    Luiz Carlos Silva Newbie

    OK, open a new thread.

    []'s

  • 9. Re: Remote JMS queue in JBoss AS 7.1
    Chris Lott Newbie

    I am also pursuing the problem of configuring JBoss servers for local and remote queues.  To keep it as simple as possible, I have two machines running JBoss AS 7.1.1.Final.  Machine 1 has queue 1 and MDBs on machines 1 and 2 should read it.  Machine 2 has queue 2 and similarly MDBs on both machines should read it.  I have no remote clients using J2SE etc., it's just two JBoss servers cooperating (altho not in a cluster) to share a workload.

     

    tc7 seems to be pursuing the goal of configuring his application purely via standalone.xml, describing in there that a particular destination is here, another destination is over there, and such. I too like this approach but now I'm not sure whether it's possible.   I see your replies indicate a MDB has to specify the host & port where a particular destination can be read.  If we have multiple MDBs all reading the same destination (with suitable filters), it seems fairly unpleasant to repeat the host & port information in every MDB. 

     

    I also looked at the messaging documentation via the link in comment 5 but I didn't see anything about configuring local versus remote queues.  I hope it's ok to reply to this (relatively old) thread.  Thanks in advance for any further light you can shed on this configuration problem!

  • 10. Re: Remote JMS queue in JBoss AS 7.1
    Justin Bertram Master

    It's not possible to configure the activation configuration properties for an MDB in standalone*.xml.  You'll need to do that on a per-MDB basis.  If it is "unpleasant" to repeat host & port information on each MDB then you can use ejb-jar.xml with system property substitution so that the same value is used across the required MDBs.

     

    I'm not sure I understand what you're saying about "local versus remote" queues.  Can you clarify what information you're missing?

  • 11. Re: Remote JMS queue in JBoss AS 7.1
    Chris Lott Newbie

    Thanks for the quick reply.  I am almost certainly using the wrong terminology, sorry about that.  I tried to sketch the situation in the previous post: two JBoss servers, two JMS destinations. The machines are not in a JBoss cluster.  We would like to distribute the load of maintaining a destination.  Server one should own and host the queue for destination 1; server two should own and host the queue for destination two.  So on server one, I would describe destination 1 as "local" and destination 2 as "remote".  MDBs can run on either server and read from either destination.  Does this clarify what I'm asking?  Am I asking for something that just doesn't make sense?  Please straighten me out, thanks in advance.