Wildfly10 - EJB-Remote Client - no response

I'm currently migrating our code from Jboss7 to Wildfly10.
The Server itself starts up totaly fine. When trying to connect our client with the working new wildfly10 server for ejb-remote calls it just won't work.
The only thing I get to work with is the following error:

org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector setupEJBReceivers WARN: Could not register a EJB receiver for connection to remote-ip:8080 java.lang.RuntimeException: Operation failed with status WAITING at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:94) at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80) at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:161) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:118) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:281) at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:291) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:178) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146) at com.sun.proxy.$Proxy2.connect(Unknown Source) at de.cinovo.rcp.test.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:39) at de.cinovo.rcp.test.RemoteEJBClient.main(RemoteEJBClient.java:25)

Exception in thread "main" java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:de.cinovo.tcc.server-ear, moduleName:de-cinovo-tcc-server-ejb-6.0-SNAPSHOT, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@180542f at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:798) at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:128) 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.$Proxy2.connect(Unknown Source) at de.cinovo.rcp.test.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:39) at de.cinovo.rcp.test.RemoteEJBClient.main(RemoteEJBClient.java:25)

There is no error, warning, info or anything showing up in the server log, while trying to connect.
There is some action on the port via tcp while watching during a call attempt.

The realy funny part is:
If I use the same wildfly setup on my local machine, the exact same connection method works, but only while using localhost as the ip address within the jboss-ejb-client.properties. As soon as I change the ip into 127.0.0.1 or my current ip address, it will fail with the same error as above.

Relevant information:

Wildfly will respond to a telnet on port 8080
Wildfly is the only service listening on 8080
My /etc/hosts is correctly configured
Changing the port doesn't fix the problem
Wildfly Version 10.1.0.Final

Relevant parts from my standalone.xml

<subsystem xmlns="urn:jboss:domain:remoting:3.0">
    <endpoint/>
    <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
</subsystem>
[...]
<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
    [...]
</subsystem>
[...]
<interfaces>
    <interface name="public">
        <any-address/>
    </interface>
</interfaces>
[...]
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="http" interface="public" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
[...]
</socket-binding-group>

My jboss-ejb-client.properties

endpoint.name=client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=<host-ip>
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.username=<usernmae>
remote.connection.default.password=<pswd>

Client-Code

final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
final Context context = new InitialContext(jndiProperties);
[...]
return context.lookup("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName);

EJB-Client-Maven-Dependency :

<dependency>
    <groupId>org.wildfly</groupId>
    <artifactId>wildfly-ejb-client-bom</artifactId>
    <version>10.1.0.Final</version>
    <type>pom</type>
</dependency>

Anyone out there who had the same problem and knows what I'm doing wrong?

回答1:

Looks like there is a missing definition in the standalone.xml in the socket.binding-group:

<outbound-socket-binding name="remote-ejb">
  <local-destination socket-binding-ref="http"/>
</outbound-socket-binding>

回答2:

So for everybody interested, here is the solution to my problem: based on the comment by Steve C and the help of a friend, we figured out that the problem is not server based.

It appears that there are some antivirus programs, which do something with your HTTP messages, as soon as the HTTP-upgrade negotiations with the Wildfly/server are done. They seem to manipulate the sent/received packages, which leads to the problem in the client, as it is no longer able to understand the answers. Therefore it never gets to react, since the package appears to have been lost - hence the IoFuture exception and EJB receiver not found.

Long story short: removing the antivirus program from our systems (in our case Bitdefender) leads to everything working as intended...