如何在Wildfly 10上查找远程JMS队列

Question

It's amazing that i can't find a working example of how to send a message to a Wildfly 10 jms queue. It seems every version of Jboss had a different way of doing this so i can find a few examples but each one addresses a different version and none for Wildfly 10.

what I'm trying to do is send a message from a master wildfly instance (running on machine 1) to a JMS queue hosted on a slave wildfly instance (running on machine 2-n). In other words, i may have several slave wildfly instances.

I've added to the standalone-full.xml of each slave instance the following:
1) In the global-modules element

<module name="org.jboss.remote-naming" slot="main"/>

2) The queue is defined as

<jms-queue name="JobTaskMDB" entries="queue/JobTaskExecuterQueue java:jboss/exported/queue/JobTaskExecuterQueue"/>

3) Every slave has the guest user

The only thing I've added to the standalone-full.xml of the master instance is (1) above

Given a machine name, such as "WILDD250148-8C9", how can i selectively send a message from the master Wildfly instance to the queue of the specified machine hosting one of the slave instances?

So far I can't even get passed the lookup of the queue. I've tried the following code:

String server = "WILDD250148-8C9";
final Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, org.jboss.naming.remote.client.InitialContextFactory.class.getName());
env.put(Context.SECURITY_PRINCIPAL, "guest"); //has been added to all slaves
env.put(Context.SECURITY_CREDENTIALS, "guest"); 
String url = 
    //"queue/JobTaskExecuterQueue";
    //"http-remoting://" + server + ":8080";
    //"tcp://" + server + ":5445";
    "jnp://" + server + ":1099";
env.put(Context.PROVIDER_URL, url);  
env.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
remoteContext = new InitialContext(env);
String lookupName = 
    //"java:jboss/exported/queue/JobTaskExecuterQueue"; 
    //"JobTaskMDB";
    "queue.queue/JobTaskExecuterQueue";
Object x = remoteContext.lookup(lookupName);

I always get "javax.naming.CommunicationException: Failed to connect to any server", for example

 javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [jnp://WILDD250148-8C9:1099 (No connection provider for URI scheme "jnp" is installed)]

or

javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [tcp://WILDD250148-8C9:5445 (No connection provider for URI scheme "tcp" is installed)]

when I used the url "http-remoting://" + server + ":8080" I got the exception:

javax.naming.CommunicationException: Failed to connect to any server. Servers tried: [http-remoting://WILDD250148-8C9:8080 (Operation failed with status WAITING after 5000 MILLISECONDS)] [Root exception is java.net.ConnectException: Operation failed with status WAITING after 5000 MILLISECONDS]

Obviously i don't even know which provider URL to use.

what am i missing here?

Answer 1

The correct URL provider for WildFly 10 is http-remoting . This works for me with Wildfly 10.1:

    Properties props = new Properties();
    props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
    props.put(Context.PROVIDER_URL, "http-remoting://127.0.0.1:8080");
    props.put(Context.SECURITY_PRINCIPAL, "user");
    props.put(Context.SECURITY_CREDENTIALS, "password");
    InitialContext ctx = new InitialContext(props);
    ActiveMQConnectionFactory cf = (ActiveMQConnectionFactory) ctx.lookup("jms/RemoteConnectionFactory");
    ActiveMQQueue queue = (ActiveMQQueue) ctx.lookup("queue/JobTaskExecuterQueue");

If the JNDI name of the queue is java:jboss/exported/queue/JobTaskExecuterQueue then from the client, use queue/JobTaskExecuterQueue (it's relative to the java:jboss/exported/ namespace)

Remove this line, this is not needed: env.put(Context.URL_PKG_PREFIXES,"org.jboss.naming:org.jnp.interfaces");

If you're getting

Operation failed with status WAITING after 5000 MILLISECONDS

then it means that the connection got stuck for more than 5 seconds for some probably different reason, like a firewall, slow network or something - the client code is probably correct.