How to configure an EJB client in JBoss EAP 6 / 7.0

Solution Verified - Updated

Environment

  • Red Hat JBoss Enterprise Application Platform (EAP)
    • 7.0
    • 6.x

Issue

  • How to configure an EJB client in JBoss EAP 6 ?
  • How to use scoped contexts in EJB Client for JBoss EAP 6 ? What are the advantages of scoped context ?
  • How to access a remote EJB in EAP 6?
  • The client is successfully able to communicate with local JBoss hosted EJBs but throws errors while communicating with remote EJBs.
  • What JNDI names should be used in EJB Client for JBoss EAP 6?
  • We have a standalone remote EJB Client calling an EJB deployed in JBoss. But we do not have jboss-ejb-client.properties. Can we specify client properties programmatically in EJB client?
  • Is it possible to call EJBs from separate applications that's backward compatible with JBoss EAP 5.1? How to call EJB from a client in EAP 6?
  • Username and Password is visible while using jboss-ejb-client.properties, Is there any other way to connect the EJB client using xml files?
  • What configuration needs to be done for EJB client authentication in standalone*-*.xml file in EAP 6?
  • Is it mandatory to set property "jboss.naming.client.ejb.context" to true?
  • How to perform EJB lookup programmatically without using @EJB ?
  • How to configure an EJB client in the migration from EAP 5.1.1 to EAP 6.2?
  • How to invoke an unsecure BeanManage or EJB method in EAP 6 from a remote client?
"javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction".
  • When calling a remote EJB Service within an EJB implementation using TransactionManagementType.CONTAINER we encounter transaction management issues (ARJUNA016053: Could not commit transaction) when the ejbRootNamingContext and jndiContext are closed. Not invoking the context close statements lead to remoting3.ProtocolExceptions complaining about too many open channels.
  • The EJB transaction policy is set to CONTAINER which delegates all the transaction handling to the JBOSS EJB container. The application itself does not do any transaction handling.
  • Could it be that this particular part is still buggy in JBOSS 6.3.0 and the bug that was fixed for 6.1.1 was only done for other transaction policies?
  • Seeing this exception on client:
Exception in thread "main" java.lang.NullPointerException
        at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:102)
  • Unable to do EJB remote lookup, getting NameNotFoundException on jndi name. We are trying to get the ejb remote object by providing the below properties to the Initial Context:
Context.INITIAL_CONTEXT_FACTORY -> org.jboss.naming.remote.client.InitialContextFactory
PROVIDER_URL -> remote://localhost:4447

  • We are getting NameNotFoundException on jndi name we are providing.

  • After EJB calls, there are lots of local connections(127.0.0.1) being created and not closed. This is making the server very slow in due course of time.

  • Getting EJBCLIENT000025 Exception during invocation of the EJB

  • How to achieve trust domain in 2 jboss instances, where these 2 instances will not be in cluster mode and where it will be possible to call remote EJB in EAP 6 from an EJB client which is also in EAP 6?

Resolution

Note

If the EJB is in the same JVM as the Client that is calling it, then the Client should follow the JavaEE spec and defined Portable JNDI Naming Syntax such as java:global/, java:app/, java:module as described in What are the allowed JNDI name formats for EJBs in EAP 7 / 6 according to EE6+.
If the Client is not in the same JVM as the EJB, then the ejb: / ejb-client methods described below would be used or the EJB over IIOP spec method as described in: How to expose an EJB via IIOP and call it in JBoss EAP 7 / 6

ModeJNDI
In-VMjava:global/, java:app/, java:module
Not in-VMEAP 7.1+: ejb:/, EAP7-:/app-name

in-VM example:

public void callEjbRemoteInterfaceInVM() {
   HelloRemote ejbRemote = new InitialContext().lookup("java:global/helloWorld/helloWorld-ejb/HelloWorldSLSB!org.jboss.examples.ejb.HelloRemote");
      ejbRemote.helloWorld();
}
public void callEjbLocalInterfaceInVM() {
   HelloRemote ejbLocal = new InitialContext().lookup("java:global/helloWorld/helloWorld-ejb/HelloWorldSLSB!org.jboss.examples.ejb.HelloLocal"); // in-VM example
      ejbLocal.helloWorld();
}

EAP 6 still uses JNDI and InitialContext to look up an EJB client proxy, but many things have changed between EAP 5 and 6 regarding how the EJB client operates and how to look up and configure the EJB proxy.

Java EE 6 introduced a new standard for looking up EJBs in JNDI. Please read Content from docs.jboss.org is not included.this document for details. The examples in this document utilize the new format.

You can choose to use either the ejb: or remote: protocol when looking up your EJB client using your InitialContext, but it's recommended that you use ejb: if at all possible. The use of ejb: takes advantage of EJB client facilities that better manage the remoting connection lifecycle.

Also note that the ejb-client (ejb:) method of invoking EJBs is not using remote JNDI calls.

Standalone client (client is not running inside of JBoss EAP 6)

Logging Notes

The JBoss EJB client stack uses Content from github.com is not included.JBoss Logging as its logging facade 1. There are several choices for a logging backend (in order of preference):

  • JBoss LogManager
  • Log4J
  • SLF4J
  • java.util.logging (JUL), i.e. JDK logging

JBoss LogManager is the fully supported and recommended option, and its classes are already included in jboss-client.jar. To enable this option, though, you need to add the following system property: -Djava.util.logging.manager=org.jboss.logmanager.LogManager. JBoss LogManager needs a logging.properties for its configuration. See the attached standalone-client-logging-config-example.zip which contains an example logging configuration for JBoss LogManager, or use the logging.properties found in the EAP installation as a starting point.

You can use Log4J or SLF4J by including the respective libraries in your client's classpath and optionally configuring the backend logging framework in your code. Make sure to not set the java.util.logging.manager system property if you want to use Log4J or SLF4J

If the java.util.logging.manager system property is not set and neither Log4J nor SLF4J are provided on the client's classpath, then JBoss Logging will fall back to JDK logging. Its default configuration is to print basic messages to the console only, though a logging.properties can be used to configure JDK logging, if desired.

Option 1 - Using jboss-ejb-client.properties (Recommended)

Use jboss-ejb-client.properties and place it on the clients classpath, then use the code below to lookup EJBs:

  • jboss-ejb-client.properties
            endpoint.name=client-endpoint
            remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
            remote.connections=node1
            remote.connection.node1.host=192.168.1.105
            remote.connection.node1.port = 4447
            remote.connection.node1.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
            remote.connection.node1.username=appuser
            remote.connection.node1.password=apppassword

  • Note that if EJB applications are used on multiple servers (in non-clustered EJB case) then for 3-server case remote.connections=node1 would be changed to remote.connections=node1,node2,node3 and host, port, username, password, connect.options, etc. above would contain entries for each of node1,node2, node3.

  • Example client code to lookup EJB

            final Hashtable jndiProperties = new Hashtable();
            jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
            Context context = new InitialContext(jndiProperties);
            context.lookup("ejb:TestTimer/TestTimerEJB/TimerExampleBean!org.example.jboss.timer.TimerExample");

In this code we are creating a JNDI InitialContext object by passing it a JNDI property. The Context.URL_PKG_PREFIXES is set to org.jboss.ejb.client.naming. This is necessary because we should let the JNDI API know what handles the ejb: namespace that is used in the JNDI names for lookup. The "org.jboss.ejb.client.naming" has a URLContextFactory implementation which will be used by the JNDI APIs to parse and return an object for ejb: namespace lookups.

Option 2 - Using JBoss EJB Client API to programatically configure (Recommended)

Use the following code snippet to programmatically configure it, but note it requires org.jboss.* classes which are included in jboss-client.jar, found in $EAP_HOME/bin/client/ .
Notes:

  • This configuration defines the configuration for the JVM (assuming the jboss-client classes are only in one classloader). If there are multiple classloaders containing jboss-client classes and this configuration method is used, then the remote connection used would depend on which classloader the client code sees.
  • The initialization must not be used more than once, if initialisized the connection is kept until a new one.
    If the initialization is done with a high frequency (i.e. each invocation) this will cause resource problems or throw Exceptions
  • The invocation of EJB's should use an existing and cached proxy for it in to get the full power of a cluster if the EJB is deployed in a clustered environment.
    In any case it is a good practice to keep the proxy to save resources and prevent from the initialization.
import org.jboss.ejb.client.EJBClientConfiguration;
import org.jboss.ejb.client.PropertiesBasedEJBClientConfiguration;
import org.jboss.ejb.client.ContextSelector;
import org.jboss.ejb.client.EJBClientContext;
import org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector;

    public void initEJBClient() {
            Properties p = new Properties();
            p.put("remote.connections", "node1");
            p.put("remote.connection.node1.port", "4447");  // the default remoting port, replace if necessary
            p.put("remote.connection.node1.host", "localhost");  // the host, replace if necessary
            p.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false"); // the server defaults to SSL_ENABLED=false
            ...
            EJBClientConfiguration cc = new PropertiesBasedEJBClientConfiguration(p);
            ContextSelector<EJBClientContext> selector = new ConfigBasedEJBClientContextSelector(cc);
            EJBClientContext.setSelector(selector);
    }

    Hello helloProxy;
    public void setProxy() {
            Properties contextProperties = new Properties();
            contextProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
            Context context = new InitialContext(contextProperties);
            helloProxy = (Hello) context.lookup("ejb:/sample/UnsecureHelloBean!sample.Hello");
    }

    public void myBusinessInvocation() {
        ...
        System.out.println(helloProxy.hello());
        ...
    }

   public void cleanupEJBClient() {
        EJBClientContext.getCurrent().close();
   }
  • Note that if EJB applications are used on multiple servers (in non-clustered EJB case) then for 3-server case p.put("remote.connections", "node1"); would be changed to p.put("remote.connections", "node1,node2,node3"); and host, port, username, password, connect.options, etc. above would contain entries for each of node1,node2, node3.
  • Note that a call to EJBClientContext.getCurrent().close() should be made after finishing with the EJB invocations.

Option 3 - Configuring using scoped context in the client code EAP 6.1+ ejb: protocol

These options are available only for >= EAP 6.1 and take advantage of Content from issues.jboss.org is not included.EJBCLIENT-34. This allows you to use NO JBoss classes, no properties file and configure everything in the InitialContext properties.

Note: ejb-client scoped context requires more resources as the client application is creating connections and managing them. It also has other limitations. For the best performance, it is recommended to NOT use scoped context. Applications that require a large number of concurrent scoped context calls are recommended to NOT use scoped context if possible due to the resources required. Specifying clustering options is not really necessary when using scoped context, as specifying multiple remote connections effectively simulates clustering HA & load balancing, and the scoped context will be closed after the call, so setting up clustering connections does not provide a benefit.

  • Configure all options in the Properties map passed into your InitialContext constructor, with the Content from docs.jboss.org is not included.scoped context option, basically making the EJB client use only the host name defined in the Properties map, rather than determining the EJB receiver to use based on the client application configuration.

Note: node1 used in the properties below is arbitrary, it is just a name to group the properties (host, port, username, password, ...) for a given connection configuration together. remote.connections is a comma delimited string that specifies the connection configurations to use.

Properties p = new Properties();
p.put("remote.connections", "node1");
p.put("remote.connection.node1.port", "4447");  // the default remoting port, replace if necessary
p.put("remote.connection.node1.host", "localhost");  // the host, replace if necessary
p.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false"); // the server defaults to SSL_ENABLED=false
p.put("remote.connection.node1.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");

//these 2 lines below are not necessary, if security-realm is removed from remoting-connector
p.put("remote.connection.node1.username", "user");
p.put("remote.connection.node1.password", "password");

...
p.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
p.put("org.jboss.ejb.client.scoped.context", true); // enable scoping here

Context context = new InitialContext(p);
Context ejbRootNamingContext = (Context) context.lookup("ejb:");
try {
   final TimerExample bean = (TimerExample) ejbRootNamingContext.lookup("TestTimer/TestTimerEJB/TimerExampleBean!org.example.jboss.timer.TimerExample");
   bean.doSomething();
} finally {
   try { 
       ejbRootNamingContext.close();
   } catch(Exception e) { }
   try { 
       context.close();
   } catch(Exception e) { }
}

  • Note that if EJB applications are used on multiple servers (in non-clustered EJB case) then for 3-server case p.put("remote.connections", "node1"); would be changed to p.put("remote.connections", "node1,node2,node3"); and host, port, username, password, connect.options, etc. above would contain entries for each of node1,node2, node3.

  • If your security-realm uses or , e.g.:

<security-realm name="ejbSecurityRealm">
    <authentication>
      <jaas name="ejbSecurityDomain"/>
    </authentication>
</security-realm>

add the following line in the client code:

prop.put("remote.connection.node1.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");

Option 4 - Configuring using remote: protocol in the client code

  • This is deprecated and not recommended for looking up EJBs.
  • Make sure you hold a reference to the InitialContext as long as the EJB proxy is being used. 2
  • Make sure you close the context when done.
  • Does not support clustered EJB.
  • Does not work well under high load
  • Using Remote Naming for EJB calls is NOT recommended if possible, given it requires more resources / connections.
final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
jndiProperties.put("jboss.naming.client.ejb.context", true);
jndiProperties.put("java.naming.factory.initial", "org.jboss.naming.remote.client.InitialContextFactory");
jndiProperties.put("java.naming.provider.url", "remote://localhost:4447");
jndiProperties.put(Context.SECURITY_PRINCIPAL,"user");  // add this user as ApplicationUser via script add-user.sh
jndiProperties.put(Context.SECURITY_CREDENTIALS, "password");

Context context = new InitialContext(jndiProperties);
TimerExample bean = context.lookup("TestTimer/TestTimerEJB/TimerExampleBean!org.example.jboss.timer.TimerExample");
// make ejb calls
// close the context when done calling the ejb to close the remote connection
try {
    if(context != null)
        context.close();
} catch(Exception e) {
}

Client in EAP 6/7.0 calling an EJB remote interface on EAP 6/7.0

Option 1 - Configuring remote servers in the JBoss profile (Recommended)

All of the following pieces are required to correctly configure EJB clients from within the JBoss container.

  • Client application configuration

    • jboss-ejb-client.xml goes in the WEB-INF if the top level deployment is a war or in the top level deployment's META-INF if not a war

          <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.0">
      <client-context>
        <ejb-receivers>
          <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection"/>
        </ejb-receivers>
      </client-context>
    </jboss-ejb-client>

  • Client application code

      final Hashtable props = new Hashtable();
  // setup the ejb: namespace URL factory
  props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
  // create the InitialContext
  final Context context = new javax.naming.InitialContext(props);

  final Greeter bean = (Greeter) context.lookup("ejb:myapp/myejb/GreeterBean!" + org.myapp.ejb.Greeter.class.getName());

  • JBoss Profile configuration: This is a configuration that goes in your standalone.xml or domain.xml.

  1. Create a security realm on the client server (ie. the base64 decoded password() created on the server side using "./add-user.sh")

Standalone Mode

/core-service=management/security-realm=ejb-security-realm:add()
/core-service=management/security-realm=ejb-security-realm/server-identity=secret:add(value="cmVkaGF0MSE=")

Domain Mode (host master used in this example)

/host=master/core-service=management/security-realm=ejb-security-realm:add()
/host=master/core-service=management/security-realm=ejb-security-realm/server-identity=secret:add(value="cmVkaGF0MSE=")

The xml added looks like: 

<management>
  <security-realms>
    ...
    <security-realm name="ejb-security-realm">
      <server-identities>
        <secret value="cmVkaGF0MSE="/>
      </server-identities>
    </security-realm>
    ...
  </security-realms>
  ...
</management>

2.Create a outbound-socket-binding on the "Client Server"

Standalone Mode

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-socket-ejb:add(host=localhost, port=4447)

Domain Mode

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-socket-ejb:add(host=server, port=4447)

The xml added looks like: 

            <socket-binding-group name="standard-sockets" 
                                  default-interface="public" 
                                  port-offset="${jboss.socket.binding.port-offset:0}">
                    ...
              <outbound-socket-binding name="remote-socket-ejb">
                <remote-destination host="localhost" port="4447"/>
              </outbound-socket-binding>
            </socket-binding-group>

3.Create a "remote-outbound-connection" which uses this newly created "outbound-socket-binding"

Standalone Mode

/subsystem=remoting/remote-outbound-connection=remote-ejb-connection:add(outbound-socket-binding-ref=remote-socket-ejb,security-realm=ejb-security-realm,username=ejb)
/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=SASL_POLICY_NOANONYMOUS:add(value=false)
/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=SSL_ENABLED:add(value=false)

/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=KEEP_ALIVE:add(value=true)
/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL:add(value=50000)
/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=READ_TIMEOUT:add(value=60000)

Domain Mode (default profile used in this example)

/profile=default/subsystem=remoting/remote-outbound-connection=remote-ejb-connection:add(outbound-socket-binding-ref=remote-socket-ejb,security-realm=ejb-security-realm,username=ejb)
/profile=default/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=SASL_POLICY_NOANONYMOUS:add(value=false)
/profile=default/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=SSL_ENABLED:add(value=false)

/profile=default/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL:add(value=50000)
/profile=default/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=KEEP_ALIVE:add(value=true)
/profile=default/subsystem=remoting/remote-outbound-connection=remote-ejb-connection/property=READ_TIMEOUT:add(value=60000)

The xml added looks like: 

            <subsystem xmlns="urn:jboss:domain:remoting:1.1">
            ....
              <outbound-connections>
                <remote-outbound-connection name="remote-ejb-connection" 
                                            outbound-socket-binding-ref="remote-socket-ejb" 
                                            security-realm="ejb-security-realm" 
                                            username="ejb">
                  <properties>
                    <property name="SASL_POLICY_NOANONYMOUS" value="false"/>
                    <property name="SSL_ENABLED" value="false"/>
                    <property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="50000"/>
                    <property name="KEEP_ALIVE" value="true"/>
                    <property name="READ_TIMEOUT" value="60000"/>
                  </properties>
                </remote-outbound-connection>
              </outbound-connections>
            </subsystem>

Option 2 - Configuring using scoped context in the client code

This option is available only for >= EAP 6.1 and takes advantage of Content from issues.jboss.org is not included.EJBCLIENT-34. This allows you to use NO JBoss classes, no properties file and configure everything in the InitialContext properties.

  • Configure all options in the Properties map passed into your InitialContext constructor, with the Content from docs.jboss.org is not included.scoped context option, basically making the EJB client use only the host name defined in the Properties map, rather than determining the EJB receiver to use based on the client application configuration.

Note: ejb-client scoped context requires more resources as the client application is creating connections and managing them. It also has other limitations. For the best performance, it is recommended to NOT use scoped context. Applications that require a large number of concurrent scoped context calls are recommended to NOT use scoped context if possible due to the resources required. Specifying clustering options is not really necessary when using scoped context, as specifying multiple remote connections effectively simulates clustering HA & load balancing, and the scoped context will be closed after the call, so setting up clustering connections does not provide a benefit.
The approach will not work if CMT is used and the transaction span both EJB's, in this case a commit/rollback will fail if the scoped-context is closed inside of the invoking method context!

  • Note a module dependency on the module org.jboss.xnio to be specified in the applications jboss-deployment-structure.xml or MANIFEST.MF Dependencies so that the application can specify the xnio options below.
Properties p = new Properties();
p.put("remote.connections", "node1");
p.put("remote.connection.node1.port", "4447");  // the default remoting port, replace if necessary
p.put("remote.connection.node1.host", "localhost");  // the host, replace if necessary
p.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false"); // the server defaults to SSL_ENABLED=false

//these 3 lines below are not necessary, if security-realm is removed from remoting-connector
p.put("remote.connection.node1.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");
p.put("remote.connection.node1.username", "user");
p.put("remote.connection.node1.password", "password");

...
// if the ejb is clustered, add the following lines...otherwise the client will log an 
// exception (JBREM000200) even though the remote ejb call completes successfully
p.put("remote.clusters", "ejb");
p.put("remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false"); 
p.put("remote.cluster.ejb.username", "user");
p.put("remote.cluster.ejb.password", "password");

...
p.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
p.put("org.jboss.ejb.client.scoped.context", true); // enable scoping here

Context context = new InitialContext(p);
Context ejbRootNamingContext = (Context) context.lookup("ejb:");
try {
   final TimerExample bean = ejbRootNamingContext.lookup("TestTimer/TestTimerEJB/TimerExampleBean!org.example.jboss.timer.TimerExample");
   bean.doSomething();
} finally {
   try { 
       ejbRootNamingContext.close();
   } catch(Exception e) { }
   try { 
       context.close();
   } catch(Exception e) { }
}

Specify a module dependency on org.jboss.xnio if org.xnio.Options are specified in the scoped context configuration properties such as: 

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

Option 3 - Configuring using remote: protocol in the client code

  • This is deprecated and not recommended for looking up EJBs.
  • Make sure you hold a reference to the InitialContext as long as the EJB proxy is being used. 2
  • Make sure you close the context when done.
  • Does not support clustered EJB.
  • Using Remote Naming for EJB calls is NOT recommended if possible, given it requires more resources / connections.

Warning: The approach will not work if CMT is used and the transaction span both EJB's, in this case a commit/rollback will fail if the initialContext is closed inside of the invoking method context!

final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
jndiProperties.put("jboss.naming.client.ejb.context", true);
jndiProperties.put("java.naming.factory.initial", "org.jboss.naming.remote.client.InitialContextFactory");
jndiProperties.put("java.naming.provider.url", "remote://localhost:4447");
jndiProperties.put(Context.SECURITY_PRINCIPAL,"user");  // add this user as ApplicationUser via script add-user.sh
jndiProperties.put(Context.SECURITY_CREDENTIALS, "password");

Context context = new InitialContext(jndiProperties);
TimerExample bean = context.lookup("TestTimer/TestTimerEJB/TimerExampleBean!org.example.jboss.timer.TimerExample");
// make ejb calls
// close the context when done calling the ejb to close the remote connection
try {
    if(context != null)
        context.close();
} catch(Exception e) {
}

Additional Notes

If there is a firewall, or other network devices, between your client and server, it may be possible to configure the closing of idle connections after some timeout.
If this is possible in your setup, it is a good idea to configure a heartbeat, so that this does not cause the connection to be closed. See "EJB invocation gets failed with error 'Connection reset by peer" for details.

Clustering Notes

See Clustered EJB in JBoss EAP 6
See This content is not included.7.7. Clustered Enterprise JavaBeans

Related Solutions

Additional code examples and documentation

1

A logging facade is defined as an API used by application/framework code to send log messages to a "backend" logging framework, e.g. Log4J or java.util.logging (JUL).
2: If the InitialContext gets garbage collected during an EJB invocation, there are various kinds of connection errors that can happen, but all errors are caused by the InitalContext forcefully closing the remoting channel.

Root Cause

Syntax for stateless beans:

ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>

For stateful beans:

ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>?stateful

Diagnostic Steps

  • Is the client a standalone java application or is it running in another JBoss EAP 6.x server? Or is it in another application server or servlet container?

If you are having an issue with an EJB client calling an EJB:

  • Review the boot.log & server.log from both client and server side when the issue occurs.
  • Make sure the client application is configured correctly depending on if it is running in JBoss EAP 6.x or standalone JVM client or other application server.
  • Review the JBoss Profile config (standalone*.xml or domain.xml) from the client and server machines.
  • Review the jboss-ejb-client.properties (when client is not running in EAP 6) & jboss-ejb-client.xml (when client is running in EAP 6) from the client application.
  • Review the client code where it is looking up the EJB and invoking it.
    • Make sure it is configured correctly for either ejb: or remote: but not mixing.
    • If using remote:, make sure you are holding a reference to the InitialContext object and not closing it.
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.