Problems accessing EJB in JBoss AS 7.x from Tomcat 6

Question

I am trying to make some remote calls to some EJB running inside a JBoss AS 7.1.1 final from my Servlet running under Tomcat 6. The EJBs are closed source and accessed from some given jars (closed code), which use a Delegate-Pattern to wrap the access to the stateless Beans.

After days of struggling with the right configuration for the jndi-lookup, I found different configurations, which all make different problems.

Solution A:

Since Tomcat 6 has it's own jndi, simply putting a jndi.properties (like it works fine if accessing the EJBs from a simple java application) in the classpath, did not work. Instead I pass the properties in an hashtable to the delegate's constructor like this:

Hashtable<String, String> jndiProperties = new Hashtable<String, String>();
jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.as.naming.interfaces:org.jboss.ejb.client.naming");
jndiProperties.put(Context.PROVIDER_URL, "remote://10.10.10.10:4447");
jndiProperties.put(Context.SECURITY_PRINCIPAL, "user");
jndiProperties.put(Context.SECURITY_CREDENTIALS, "password");

Delegate someDelegate = new DelegateImpl(jndiProperties);

This leads to the following exception (which does not occur when doing the same from a simple java application):

java.lang.IllegalStateException: No EJB receiver available for handling [appName:eex,modulename:eex-ejb,distinctname:] combination for invocation context 

Some research advised me to try....

Solution B:

I added the following line:

jndiProperties.put("jboss.naming.client.ejb.context", "true");

Now the lookup and remote call works fine, but after some calls I get the following exception (which also occurs when doing the same from a simple java application):

org.jboss.remoting3.ProtocolException: Too many channels open

As far as I understand, with jboss.naming.client.ejb.context set to true, a new EJBClientContext is created for every lookup on JBoss AS side and it seems, that the Delegate does not close it correctly. There's a detailed explanation on how to correctly close all contexts under https://docs.jboss.org/author/display/WFLY8/Scoped+EJB+client+contexts.

Since I don't own the Delegate-source-code, there is no way to close the contexts correctly.

So I tried...

Solution C:

There's a whole different way to do the lookup: by providing a jboss-ejb-client.xml instead of a jndi.properties. This works well together with tomcat and the lookup is fine with this configuration:

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.host=10.10.10.10
remote.connection.default.username=user
remote.connection.default.password=password

However, with this configuration I run into the following exception from time to time (I can not reproduce it so far, the exception just occurs sometimes):

ERROR: JBREM000200: Remote connection failed: the timeout for the connection expired
...and some lines later...
Caused by: java.io.IOException: Channel Channel ID 841ded9c (outbound) of Remoting connection 00dcc89a to null has been closed

Any help is highly appreciated...

Answer 1

So... I also had this problem (and others) and I will try to explain here (I do not know if in the correct terms) what I intended to do and how I solved, it worked for me. We made several remote ejb calls, and eventually we had the following problem:

Caused by: java.io.IOException: Channel Channel ID fa8f69c7 (outbound) of Remoting connection 0196f4b5 to null has been closed (https://developer.jboss.org/thread/198390)

This happened due to remote calls where the context was not managed, and hence JBoss itself is in charge of managing the communication channels automatically. But with that, over time this connection was idle and eventually happened to "lose" this connection, due to known or unknown reasons (firewall, connection limit, when uploading a new version)

So to solve this first problem, I reviewed the following documentation:

https://docs.jboss.org/author/display/WFLY8/Scoped+EJB+client+contexts

After placing the following property:

props.put ("org.jboss.ejb.client.scoped.context", "true");

We then manage the ejb scope, so we can open and close the communication channels. so I came across to another problem:

Unrecognized SSL message, plaintext connection

This theoretically happens because the server does not support ssl communication as default. To resolve this, you must put the following property:

props.put ("remote.connection." + ConnectionName "+ connect.options.org.xnio.Options.SSL_ENABLED", "false");

(you must fill in the host and port in the same way)

And then we fall into another problem:

Invalid option 'org.xnio.Options.SSL_ENABLED' in property 'remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED': java.lang.IllegalArgumentException: Class 'org.xnio.Options' not found

This is due to the lack of dependence on XNIO. You could put the dependencies of jboss-ejb-client on your pom that would solve (in my case I used jboss-as-ejb-client-bom), but it partially solved for me. When it was in different ears, ive got the same problem, until finally I put this configuration in jboss-deployment-structure.xml to export dependency:

<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <module name = "org.jboss.xnio" export = "true" />
    </dependencies>
  </deployment>
</jboss-deployment-structure>

Finally seeing the class, it can instantiate and set SSL_ENABLED to false. Now I manage the ejb scope manually and I can open and close the channels, solving closed connections problems.

Hope it helps.

Answer 2

ok, I finally could solve my problem.

I still don't know the answer to the problems of solution A.

I described the possible problems of solution B.

The exception of solution C was caused by our firewall, which dropped the session table entry after some minutes of inactivity. I solved it by adding

remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL=60000

to jboss-ejb-client.properties.

This causes a "ping" from the client to the JBoss AS every minute, which prevents the firewall from dropping the session entry.