Are you seeing a particular error message or exception when you try to send to the remote server? If so, please paste the full details.
My apologizes for forgetting to describe the error I am a seeing.
From the Test report:
Test set: com.chp.valuequest.controller.MessagingTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 43.551 sec <<< FAILURE! - in com.chp.valuequest.controller.MessagingTest
testProcessCensusRemote(com.chp.valuequest.controller.MessagingTest) Time elapsed: 1.765 sec <<< ERROR!
javax.jms.JMSSecurityRuntimeException: HQ119031: Unable to validate user: guest
From the server:
14:49:18,138 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "opportunity-services.war" (runtime-name : "opportunity-services.war")
2015-03-06 14:49:22,964 INFO [com.chp.valuequest.controller.MessagingTest] (default task-1) testProcessCensusRemote
14:49:22,964 INFO [com.chp.valuequest.controller.MessagingTest] (default task-1) testProcessCensusRemote
2015-03-06 14:49:23,108 INFO [org.xnio] (default task-1) XNIO version 3.2.0.Final
14:49:23,108 INFO [org.xnio] (default task-1) XNIO version 3.2.0.Final
2015-03-06 14:49:23,117 INFO [org.xnio.nio] (default task-1) XNIO NIO Implementation Version 3.2.0.Final
14:49:23,117 INFO [org.xnio.nio] (default task-1) XNIO NIO Implementation Version 3.2.0.Final
2015-03-06 14:49:23,459 INFO [org.jboss.remoting] (default task-1) JBoss Remoting version 4.0.0.Final
14:49:23,459 INFO [org.jboss.remoting] (default task-1) JBoss Remoting version 4.0.0.Final
2015-03-06 14:49:25,825 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) JBAS017535: Unregistered web context: /OpportunityServices
This looks like a standard security issue to me. I believe that when a client running on the same machine as the application server connects security is not enforced so that's likely why you don't see this same problem when you run the server locally.
I recommend you ensure the proper user is added to the server (e.g. use the "add-user" script in the "bin" directory to add an application user named "guest" with a password of "guest" belonging to the group "guest").
When I run the test on the linux box with the Wildfly instance it fails with the same error. I thought it might have to with whether the client is remote or local but this test scenario suggests otherwise.
Can you confirm that you've added the proper user in the proper group as I recommended previously?
Yes. I can confirm that there is an application user 'guest' with password 'guest' assigned a the 'guest' role.
I feel like I am overlooking something here. However the fact that it works when the client is local to the instance running on Windows, but fails when the client is local and remote to the instance running on Linux makes me think there is actually something wrong here. Don't forget that I literally copied the Wildfly installation from Linux to Windows so both of the installations should be exactly the same.
Ok I just confirmed that it works when the remote Linux client messages the instance running on Windows.
One thing you might try is setting <security-enabled>false</security-enabled> in the messaging subsystem on the server running on Linux and seeing if that gets you past the security exception which would confirm that your Windows client is actually connecting to the right server.
A few more things...
- How are you starting the server on Linux? Are you passing any command-line parameters? If so, what are they?
- Can you attach the server configuration you're using on Linux?
- Can you attach the server.log from the Linux server when you observe this problem?
Thanks to you I finally realized which of my assumptions was wrong. It was a configuration issue in the test server deployed on Linux causing the connection attempts to go to a different instance deployed on the same Linux box. I fixed the configuration and everything started to work as intended.
Another tidbit that became clear to me is that because I am using the Arquillian Wildfly Remote container capability the test client was always running in the same container where the JMS queue was configured in. So all is well ...thanks again!