将独立Java程序连接到WildFly服务器上的JMS时出错

Question

I'm having a problem with connecting to JMS on WildFly 8.0.0.Final.

I'm using a stand-alone Java program, which source code is the exact copy of HelloWorldJMSClient.java from WildFly Quickstart samples.

I have followed the provided instructions , and added quickstartUser and configured JMS .

From admin console I can see RemoteConnectionFactory

and the created test queue

I start WildFly with standalone full configuration

The server starts and seemingly successfully completes all the steps, including JMS (HornetQ) bindings:

C:\WildFly8\wildfly-8.0.0.Final\bin\standalone.bat -c standalone-full.xml
Calling "C:\WildFly8\wildfly-8.0.0.Final\bin\standalone.conf.bat"
Setting JAVA property to "C:\Program Files\Java\jdk1.8.0_05\bin\java"
Detected server admin port: 9990
Detected server http port: 8080
===============================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: "C:\WildFly8\wildfly-8.0.0.Final"

  JAVA: "C:\Program Files\Java\jdk1.8.0_05\bin\java"

  JAVA_OPTS: "-XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman"

===============================================================================

10:39:36,154 INFO  [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
10:39:37,741 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.0.Final
10:39:37,842 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Final "WildFly" starting
10:39:42,278 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
10:39:42,328 INFO  [org.xnio] (MSC service thread 1-5) XNIO version 3.2.0.Final
10:39:42,337 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.2.0.Final
10:39:42,400 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 36) JBAS010280: Activating Infinispan subsystem.
10:39:42,402 INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 47) JBAS011800: Activating Naming Subsystem
10:39:42,396 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 52) JBAS013171: Activating Security Subsystem
10:39:42,428 INFO  [org.jboss.as.jacorb] (ServerService Thread Pool -- 37) JBAS016300: Activating JacORB Subsystem
10:39:42,454 INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 56) JBAS015537: Activating WebServices Extension
10:39:42,523 INFO  [org.jboss.as.security] (MSC service thread 1-2) JBAS013170: Current PicketBox version=4.0.20.Final
10:39:42,577 INFO  [org.jboss.as.jsf] (ServerService Thread Pool -- 43) JBAS012615: Activated the following JSF Implementations: [main]
10:39:42,661 INFO  [org.jboss.as.naming] (MSC service thread 1-1) JBAS011802: Starting Naming Service
10:39:42,666 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-1) JBAS015400: Bound mail session [java:jboss/mail/Default]
10:39:42,776 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017502: Undertow 1.0.0.Final starting
10:39:42,776 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55) JBAS017502: Undertow 1.0.0.Final starting
10:39:42,819 INFO  [org.jboss.as.connector.logging] (MSC service thread 1-1) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final)
10:39:43,053 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 4.0.0.Final
10:39:43,319 INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 31) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
10:39:43,355 INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-6) JBAS010417: Started Driver service with driver-name = h2
10:39:43,646 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 55) JBAS017527: Creating file handler for path C:\WildFly8\wildfly-8.0.0.Final/welcome-content
10:39:43,707 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017525: Started server default-server.
10:39:43,715 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017531: Host default-host starting
10:39:43,874 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
10:39:44,130 WARN  [org.jboss.as.messaging] (MSC service thread 1-4) JBAS011600: AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
10:39:44,377 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-8) JBAS015012: Started FileSystemDeploymentService for directory C:\WildFly8\wildfly-8.0.0.Final\standalone\deployments
10:39:44,581 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221000: live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=C:\WildFly8\wildfly-8.0.0.Final\standalone\data\messagingjournal,bindingsDirectory=C:\WildFly8\wildfly-8.0.0.Final\standalone\data\messagingbindings,largeMessagesDirectory=C:\WildFly8\wildfly-8.0.0.Final\standalone\data\messaginglargemessages,pagingDirectory=C:\WildFly8\wildfly-8.0.0.Final\standalone\data\messagingpaging)
10:39:44,582 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221006: Waiting to obtain live lock
10:39:44,729 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221013: Using NIO Journal
10:39:44,748 WARN  [jacorb.codeset] (MSC service thread 1-2) Warning - unknown codeset (Cp1252) - defaulting to ISO-8859-1
10:39:45,033 INFO  [io.netty.util.internal.PlatformDependent] (ServerService Thread Pool -- 58) Your platform does not provide complete low-level API for accessing direct buffers reliably. Unless explicitly requested, heap buffer will always be preferred to avoid potential system unstability.
10:39:45,049 INFO  [org.jboss.as.jacorb] (MSC service thread 1-2) JBAS016330: CORBA ORB Service started
10:39:45,161 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221043: Adding protocol support CORE
10:39:45,286 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221043: Adding protocol support AMQP
10:39:45,299 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
10:39:45,305 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221043: Adding protocol support STOMP
10:39:45,391 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221034: Waiting to obtain live lock
10:39:45,392 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221035: Live Server Obtained live lock
10:39:45,472 INFO  [org.jboss.as.jacorb] (MSC service thread 1-3) JBAS016328: CORBA Naming Service started
10:39:45,890 INFO  [org.jboss.ws.common.management] (MSC service thread 1-5) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.3.Final
Connected to server
10:39:45,958 INFO  [org.jboss.messaging] (MSC service thread 1-4) JBAS011615: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor-throughput acceptor
10:39:45,961 INFO  [org.jboss.messaging] (MSC service thread 1-1) JBAS011615: Registered HTTP upgrade for hornetq-remoting protocol handled by http-acceptor acceptor
10:39:46,254 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221007: Server is now live
10:39:46,254 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221001: HornetQ Server version 2.4.1.Final (Fast Hornet, 124) [c42f74fe-ddcf-11e3-9d67-07b9140cdda2] 
10:39:46,272 INFO  [org.hornetq.core.server] (ServerService Thread Pool -- 58) HQ221003: trying to deploy queue jms.queue.testQueue
10:39:46,278 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 58) JBAS011601: Bound messaging object to jndi name queue/test
10:39:46,279 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 58) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/queue/test
10:39:46,300 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 60) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
10:39:46,301 INFO  [org.jboss.as.messaging] (ServerService Thread Pool -- 59) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
10:39:46,424 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-2) JBAS010406: Registered connection factory java:/JmsXA
10:39:46,515 INFO  [org.hornetq.ra] (MSC service thread 1-2) HornetQ resource adaptor started
10:39:46,516 INFO  [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-2) IJ020002: Deployed: file://RaActivatorhornetq-ra
10:39:46,518 INFO  [org.jboss.as.connector.deployment] (MSC service thread 1-2) JBAS010401: Bound JCA ConnectionFactory [java:/JmsXA]
10:39:46,518 INFO  [org.jboss.as.messaging] (MSC service thread 1-8) JBAS011601: Bound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
10:39:46,636 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
10:39:46,637 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
10:39:46,637 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Final "WildFly" started in 12523ms - Started 216 of 264 services (90 services are lazy, passive or on-demand)
10:40:35,457 INFO  [org.jboss.ejb.client] (XNIO-1 task-3) JBoss EJB Client version 2.0.0.Final

When I start the Java program I get the following error:

May 22, 2014 10:57:29 AM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.0.Final
May 22, 2014 10:57:29 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.0.Final
May 22, 2014 10:57:30 AM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version (unknown)
May 22, 2014 10:57:30 AM HelloWorldJMSClient main
INFO: Attempting to acquire connection factory "jms/RemoteConnectionFactory"
May 22, 2014 10:57:35 AM HelloWorldJMSClient main
SEVERE: Failed to connect to any server. Servers tried: [http-remoting://127.0.0.1:8080    
(Operation failed with status WAITING after 5000 MILLISECONDS)]

When I run it under debugger I can see that the program acquires initial JNDI context and then fails on the very first lookup .

So it seems that the program that is expecting the server on //127.0.0.1:8080 does not see the server running on this very URL.

I tried changing the URL to //localhost:8080 but it didn't make any difference.

It's quite possible that I have a stupid typo somewhere that I simply cannot notice.

Anyway, how can I further troubleshoot this situation?

CLARIFICATION (0523/14):

When I open localhost:8080 in my browser I'm getting WildFly's welcome page. Then I can go into administration panel. That is how the first two JNDI / JMS related screen captures were obtained.

From netstat with the server running:

  TCP    127.0.0.1:8080         0.0.0.0:0              LISTENING

This result is the same whether I start the server from the command line or from IntellJ IDEA.

NETWORK TRAFFIC

I believe this is a relevant part:

Link to a better view.

UPDATE (05/28/2014)

As it was pointed to me on Wildfly's Forum the following line from the log (as I kinda suspected) should've raised a red flag:

May 22, 2014 10:57:30 AM org.jboss.remoting3.EndpointImpl
INFO: JBoss Remoting version ( unknown )

Another bit of information (not sure whether it's relevant) I'm using the following jar to manually resolve dependencies:

Answer 1

Agree with @Iain. netstat -nab will list all ports and their owner process. If 127.0.0.1:8080 or 0.0.0.0:8080 is listed as LISTENING, I'd probably start Wireshark up and sniff for 8080 tcp to make sure your wildfly process is actually answering. It sounds like you're looking for basic http stuff, which wireshark will mostly decode for you.

It should go without saying that this shouldn't be done on/against your production deployment unless absolutely everything is broken and things need fixing now . After you've resolved your prod issue, you need to review your test and promotion procedures.

Things to check for tcp/http connection setup diagnostics:

1. Server doesn't hate just your client. Using an alternate machine and a known working client (or client that is somewhat similar), connect to the server. A similar client could be a browser, or netcat/telnet. If this works, your client is broken, or your server is specifically rejecting your client-under-test.
2. Server is listening. win: netstat -nab , many *nix: netstat -nlp . Look for an IP:Port LISTENING line for your server process. Maybe something else has stolen your listen port or it is in TIMEWAIT because your crashed-out server never closed it.
3. Server is receiving incoming connection request. On the server side, windows: wireshark, nix: wireshark/ tcpdump -i <interface> 'port <listenport>' . Look for incoming SYN packet from client on your listening port and the server reply. No incoming packet means blocked by network config or firewall, etc, which makes it a network debug problem. No outgoing packet usually means server is broken or misconfigured.
4. Client receives server's response. After confirming the server is completing the tcp connection but no http command comes from the client, verify the client machine receives the packets using about the same procedure. If it isn't receiving the packets the server sends, it is a network debug problem. If it is, then your client is broken.
5. Server completes protocol response. Client sends a full request like "GET / HTTP/1.1\\r\\n\\r\\n", Server replies "HTTP/1.1 200 OK".
   • Server might reply some handshaking binary instead when your client doesn't expect it for example, if you forgot SSL on your client; that's a pretty common error. SSL protocol decoding usually involves dumping out the keys on the client or server and copy them into wireshark -- At this point I usually start gdb/jdb/dtrace and dump out strings before entering ssl write and after returning from ssl read. This works because the connection is already established and reliable so unless it's doing funny things and dying, leave network analysis behind and begin a regular debug procedure.

Simple things to try when you're stumped or you've spent an hour with no progress:

1. Did you read the manual? Better late than never.
2. Change the server listening port. Something in the 10k-12k range is unlikely to conflict with anything.
3. Reduce client and server tunable threads/processes to the minimum possible to reproduce the error. If the error goes away, you'll have something to look for. If it doesn't, it's a lot easier to debug when you have fewer thread contexts to switch between in the debugger.
4. Got a support contract? Ask the vendor. Describe the diagnostics you did, usually skipping stuff that worked until one or two before the failure to give them some context. Just like asking a Stackexchange question, only you're paying them. If they don't provide prompt support, check if there are better options at the same price point and reevaluate your business needs; a great piece of software you can't get to work is significantly less useful and valuable than crappy software that works now.

Answer 2

Change the JNDI names in Wildfly administration console to these:

jms/RemoteConnectionFactory (for connection factory) jms/queue/test (for queue)