3 Replies Latest reply on Jul 16, 2013 5:26 AM by jaikiran

    Remote Stateful Session Beans

    danpeter

      Hi

       

      I have 2 jboss 7.1.1 servers. Server A has a Stateful Remote EJB deployed and Server B looks up the server using Jndi.

      The remote part is implemented as described in https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+server+instance and works.

      Server B has a jsf web interface and a sessionscoped CDI bean. This bean should lookup the SSB and keep the same reference for the duration of the session.

       

      Now I use just @Inject RemoteEJBInterface in the CDI bean and use a CDI factory to do the jndi stuff

       

      public class RemoteEnrolmentFactory {

       

          @Produces

          @SessionScoped

          public RemoteEJBInterface lookupRemoteStatefulBean() throws NamingException {

              final Hashtable jndiProperties = new Hashtable();

              jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

              final Context context = new InitialContext(jndiProperties);

              // The app name is the application name of the deployed EJBs. This is typically the ear name

              // without the .ear suffix. However, the application name could be overridden in the application.xml of the

              // EJB deployment on the server.

              // Since we haven't deployed the application as a .ear, the app name for us will be an empty string

              final String appName = "xxxx-ear";

              // This is the module name of the deployed EJBs on the server. This is typically the jar name of the

              // EJB deployment, without the .jar suffix, but can be overridden via the ejb-jar.xml

              // In this example, we have deployed the EJBs in a jboss-as-ejb-remote-app.jar, so the module name is

              // jboss-as-ejb-remote-app

              final String moduleName = "xxxxxxx";

              // AS7 allows each deployment to have an (optional) distinct name. We haven't specified a distinct name for

              // our EJB deployment, so this is an empty string

              final String distinctName = "";

              // The EJB name which by default is the simple class name of the bean implementation class

              final String beanName = "xxxxxx";

              // the remote view fully qualified class name

              final String viewClassName = xxxxxx.class.getName();

              // let's do the lookup (notice the ?stateful string as the last part of the jndi name for stateful bean lookup)

              return (RemoteEJBInterface) context.lookup("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName + "?stateful");

          }

      }

       

      Is this a acceptable way to do it? Do I need to store the InitialContext for the duration of the session?

       

      2nd problem....

      When I receive a exception from the remote SSB i see this log:

      16:30:58,533 INFO  [org.jboss.ejb.client.remoting.ChannelAssociation] (Remoting "sesstl108" task-1) Channel Channel ID d4066f5b (outbound) of Remoting connection 53ef81de to xxxxxxx can no longer process messages

       

      Then I try to connect to the SSB again....

       

      Caused by: java.lang.IllegalStateException: No EJB receiver available for handling [appName:xxxxx-ear,modulename:xxxxx,distinctname:] combination

          at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:517) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]

          at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:161) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]

          at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]

          at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]

          ... 58 more

       

      Seems like it is not reconnecting automatically. If i restart the client server it works again.

        • 1. Re: Remote Stateful Session Beans
          wdfink

          If you use a bean on a different server there are a bit more things to do. You can read the documentation and you find an example project ejb-multi-server in the quickstarts

          • 2. Re: Remote Stateful Session Beans
            danpeter

            Thanks for your reply!

             

            I changed my client code to:

             

            @Named

            @SessionScoped

            public class JsfController implements Serializable {

             

                @Resource(lookup = "ejb:my-ear/xxxxx/xxxxx!xxxxx.RemoteEjb?stateful")

                RemoteEjb remoteEJB;

             

            This solved the problem when a runtime exception was thrown from the remote ejb.

             

            If i restarted the remote ejb server and started it again I still got the "No EJB receiver available for handling" exception until i restarted the client server.

            Upgrading to EAP 6.1 solved this issue and the server reconnected with the message:

             

            11:02:34,507 INFO  [org.jboss.ejb.client.remoting] (Remoting "host" task-4) EJBCLIENT000017: Received server version 1 and marshalling strategies [river]

            11:02:34,507 INFO  [org.jboss.ejb.client.remoting] (ejb-client-context-tasks-3-thread-5) EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@3c61a8f3, receiver=Remoting connection EJB receiver [connection=Remoting connection <2d4cc7af>,channel=jboss.ejb,nodename=host]} on channel Channel ID 8128b037 (outbound) of Remoting connection 358fdb8c to xxx/xxx.xxx.xxx.xxx:4447

            • 3. Re: Remote Stateful Session Beans
              jaikiran

              There was a bug in reconnecting which was fixed in a version after 7.1.1.Final was released. Upgrading to the newer versions is the right thing to do.