Remote JMS communication works, EJB communication fails - ejb

Question

I'm currently introducing myself into Java EE, especially into how to use EJB and JMS.
The Issue in a Nutshell
I have a local client and a remote server in the internet. JMS communication works fine, EJB communication doesn't. Either communication succeeds in my local network.
The Issue in More Detail
I'm using Maven to build:
an EAR containing a couple of stateless remote EJBs and one MDB
a desktop client which includes EJB client JARs generated by Maven which are used to communicate with the server.
I'm using a WildFly application server to deploy the EAR. According to the server logs, EJBs are successfully exported. All traffic is based on http-remoting. Undertow switches protocols according to sniffed traffic as needed.
Let's take the client login as an example. The login API call is based on remote EJB communication, meanwhile JMS messages are sent.
If I run both client and server on my local machine from Eclipse, login works fine and JMS messages are processed correctly. Same applies if I run the client on a different machine in the same network. If I run the client in my local network, but the server in the internet, EJB communication fails and JMS messages are still processed correctly.
Why is that?
Log Content
The remote EJB's login method is not invoked, there are no logs. I have added log4j.logger.org.jboss.ejb.client=TRACE to log4j.properties. Thats the client logs in case of a failing API call:
2015-06-21 16:47:49 [GS Desktop Init Thread] DEBUG PropertiesBasedEJBClientConfiguration:242 - endpoint.create.options. has the following options {}
2015-06-21 16:47:49 [GS Desktop Init Thread] TRACE PropertiesBasedEJBClientConfiguration:272 - Options {} have been merged with defaults {org.xnio.Options.THREAD_DAEMON=>true} to form {org.xnio.Options.THREAD_DAEMON=>true}
2015-06-21 16:47:49 [GS Desktop Init Thread] DEBUG PropertiesBasedEJBClientConfiguration:242 - remote.connectionprovider.create.options. has the following options {org.xnio.Options.SSL_ENABLED=>false}
2015-06-21 16:47:49 [GS Desktop Init Thread] TRACE PropertiesBasedEJBClientConfiguration:272 - Options {org.xnio.Options.SSL_ENABLED=>false} have been merged with defaults {} to form {org.xnio.Options.SSL_ENABLED=>false}
2015-06-21 16:47:49 [GS Desktop Init Thread] DEBUG PropertiesBasedEJBClientConfiguration:242 - remote.connection.default.connect.options. has the following options {org.xnio.Options.SASL_DISALLOWED_MECHANISMS=>[JBOSS-LOCAL-USER],org.xnio.Options.SASL_POLICY_NOANONYMOUS=>false}
2015-06-21 16:47:49 [GS Desktop Init Thread] TRACE PropertiesBasedEJBClientConfiguration:272 - Options {org.xnio.Options.SASL_DISALLOWED_MECHANISMS=>[JBOSS-LOCAL-USER],org.xnio.Options.SASL_POLICY_NOANONYMOUS=>false} have been merged with defaults {} to form {org.xnio.Options.SASL_DISALLOWED_MECHANISMS=>[JBOSS-LOCAL-USER],org.xnio.Options.SASL_POLICY_NOANONYMOUS=>false}
2015-06-21 16:47:49 [GS Desktop Init Thread] DEBUG PropertiesBasedEJBClientConfiguration:242 - remote.connection.default.channel.options. has the following options {}
2015-06-21 16:47:49 [GS Desktop Init Thread] DEBUG PropertiesBasedEJBClientConfiguration:490 - Connection org.jboss.ejb.client.PropertiesBasedEJBClientConfiguration$RemotingConnectionConfigurationImpl#33f49f38 successfully created for connection named default
2015-06-21 16:47:49 [GS Desktop Init Thread] DEBUG PropertiesBasedEJBClientConfiguration:295 - No clusters configured in properties
2015-06-21 16:47:49 [GS Desktop Init Thread] DEBUG EJBClientPropertiesLoader:100 - Looking for jboss-ejb-client.properties using classloader sun.misc.Launcher$AppClassLoader#58644d46
2015-06-21 16:47:49 [GS Desktop Init Thread] INFO client:45 - JBoss EJB Client version 2.1.1.Final
...
2015-06-21 16:47:51 [Remoting "config-based-ejb-client-endpoint" task-4] DEBUG RemotingConnectionEJBReceiver:191 - Channel Channel ID eb5d763d (outbound) of Remoting connection 25bff644 to euve1234.vserver.de/84.46.96.86:8080 opened for context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext#3baeae68, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection#3f310404,channel=jboss.ejb,nodename=euve1234]} Waiting for version handshake message from server
2015-06-21 16:47:51 [Remoting "config-based-ejb-client-endpoint" task-5] INFO remoting:103 - EJBCLIENT000017: Received server version 2 and marshalling strategies [river]
2015-06-21 16:47:51 [GS Desktop Thread 0] INFO remoting:218 - EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext#3baeae68, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection#3f310404,channel=jboss.ejb,nodename=euve1234]} on channel Channel ID eb5d763d (outbound) of Remoting connection 25bff644 to euve1234.vserver.de/84.46.96.86:8080
2015-06-21 16:47:51 [Remoting "config-based-ejb-client-endpoint" task-6] TRACE ChannelAssociation:375 - Received message with header 0x8
2015-06-21 16:47:51 [Remoting "config-based-ejb-client-endpoint" task-6] DEBUG RemotingConnectionEJBReceiver:763 - Received module availability report for 11 modules
2015-06-21 16:47:51 [Remoting "config-based-ejb-client-endpoint" task-6] DEBUG RemotingConnectionEJBReceiver:765 - Registering module EJBModuleIdentifier{appName='GSServerEAR-0.0.1', moduleName='GSAuthManagerEjb-0.0.1', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext#3baeae68, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection#3f310404,channel=jboss.ejb,nodename=euve1234]}
2015-06-21 16:47:51 [Remoting "config-based-ejb-client-endpoint" task-6] DEBUG RemotingConnectionEJBReceiver:765 - Registering module EJBModuleIdentifier{appName='GSServerEAR-0.0.1', moduleName='GSNotificationManagerEjb-0.0.1', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext#3baeae68, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection#3f310404,channel=jboss.ejb,nodename=euve1234]}
...
2015-06-21 16:47:51 [Remoting "config-based-ejb-client-endpoint" task-6] DEBUG RemotingConnectionEJBReceiver:765 - Registering module EJBModuleIdentifier{appName='GSServerEAR-0.0.1', moduleName='GSServerEAR-0.0.1', distinctName=''} availability for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext#3baeae68, receiver=Remoting connection EJB receiver [connection=org.jboss.ejb.client.remoting.ConnectionPool$PooledConnection#3f310404,channel=jboss.ejb,nodename=euve1234]}
2015-06-21 16:47:51 [GS Desktop Thread 0] DEBUG ConfigBasedEJBClientContextSelector:174 - Registered 1 remoting EJB receivers for EJB client context org.jboss.ejb.client.EJBClientContext#3baeae68
...
2015-06-21 16:47:51 [JavaFX Application Thread] WARN GsTask:38 - API call background task failed
java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:GSServerEAR, moduleName:GSAuthManagerEjb-0.0.1, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext#63dd58c4
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:774)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:116)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
at com.sun.proxy.$Proxy7.createSession(Unknown Source)
...
Some of My Thoughts
Could the issue be caused by
Invalid IPs?
No. After moving the server, I've updated the standalone.xml configuration, and I've ensured by observing network traffic on all machines that all calls are received. JMS works.
WildFly security settings, e.g. concerning security realm configuration?
No. Login works locally. These settings should be valid after moving the server. Both JMS and EJB use the same WildFly application user. JMS works.
Could be a networking/routing issue, since EJBs are based on RMI, or some kind of firewall issue?
Probably, but JMS works. I'm not yet really used to JMS, but isn't it based on RMI? I send javax.jms.ObjectMessages. Session.createObjectMessage(Serializable object) takes a Serializable, that's why I suggest that we have RMI here, too.
Locally, WildFly runs on Windows 7. Remote, Wildfly runs on Ubuntu. I've tried Ubuntu 10/12/14 for this.
Concerning Java and WildFly: These are platform independent. Write once, run everywhere. I suggest that it is very unlikely that the problem is caused by the underlying OS. I've verified that traffic flows and JMS works.
Please correct me if I'm wrong.
Additional Notes
I know that I've provided little information so long, since I didn't want to blow up my question. Please don't hesitate to ask if you need more information. This applies to code, too.
I'm using Java SE 8 / Java EE 7. Concerning WildFly: I've tested 8.1.0.Final, 8.2.0.Final and 9.0.0.Beta2.
Please don't simply refer to online examples. I've been working on such for days already, and please keep in mind that the local communication works fine, already.
I highly appreciate any thoughts and comments on this since I got really stuck. Many thanks in advance.
Update 1: EJB Implementation, Client Context Creation and EJB Lookup
Server:
#Remote
public interface GsAuthManager {
GsClientSession createSession(String username, String password);
}
#Stateless
public class GsAuthManagerBean implements GsAuthManager {
#Override
public GsClientSession createSession(String username, String password) {
// ...
}
}
WildFly logs:
java:jboss/exported/GSServerEAR/GSAuthManagerEjb-0.0.1/GsAuthManagerBean!de.genesys.server.ejb.auth.GsAuthManager
Client:
static void initEjbClient(String serverHostname, String username, String password) {
final Properties ejbClientProps = new Properties();
ejbClientProps.put("remote.connections", "default");
ejbClientProps.put("remote.connection.default.port", "8080");
ejbClientProps.put("remote.connection.default.host", serverHostname);
ejbClientProps.put("remote.connection.default.username", username);
ejbClientProps.put("remote.connection.default.password", password);
ejbClientProps.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
ejbClientProps.put("remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");
ejbClientProps.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
EJBClientConfiguration clientConfig = new PropertiesBasedEJBClientConfiguration(ejbClientProps);
ContextSelector<EJBClientContext> selector = new ConfigBasedEJBClientContextSelector(clientConfig);
EJBClientContext.setSelector(selector);
}
static GsAuthManager initEjbProxy(String serverHostname, String username, String password) throws NamingException{
Properties props = new Properties();
props.put("jboss.naming.client.ejb.context", true);
props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");
props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
props.put(Context.PROVIDER_URL, "http-remoting://" + serverHostname + ":8080");
props.put(Context.SECURITY_PRINCIPAL, username);
props.put(Context.SECURITY_CREDENTIALS, password);
InitialContext context = new InitialContext(props); // Stripped down, original code keeps a strong reference and closes context on program termination
return (GsAuthManager) context.lookup("ejb:GSServerEAR/GSAuthManagerEjb-0.0.1/GsAuthManagerBean!de.genesys.server.ejb.auth.GsAuthManager");
}

Answer 1

In the logs you get on deploy appName='GSServerEAR-0.0.1' but when the exception occurs: appName:GSServerEAR. So I suppose, the runtime of your EAR file (when you deploy it) contains the version, and it should not.