6 Replies Latest reply on Dec 5, 2014 11:43 AM by pmm

    SLSB failover without cluster

    pmm

      We have a stateless application that uses only stateless session beans from a standalone client. We'd like to have a second WildFly AS instance for failover. We do not use any SFSBs and there is no need to synchronize any state between the servers. Simply sending a failed request to the second server would be enough.

      Can this be done without a cluster or do we need a cluster?

        • 1. Re: SLSB failover without cluster
          pferraro

          EJB invocations from a remote client using JNDI - WildFly 8 - Project Documentation Editor

           

          Yes - this can be done without a cluster.  A remote ejb client can be configured with any number of "connections".  The client will automatically load balance requests between the known connections on which a @Stateless EJB is deployed.

          • 2. Re: SLSB failover without cluster
            pmm

            Paul Ferraro wrote:

             

            EJB invocations from a remote client using JNDI - WildFly 8 - Project Documentation Editor

             

            Yes - this can be done without a cluster.  A remote ejb client can be configured with any number of "connections".  The client will automatically load balance requests between the known connections on which a @Stateless EJB is deployed.

            Is that behavior only available using JNDI? We're currently using the WildFly-specific remote ejb protocol (ejb:). We are not using the remote naming project.

            • 3. Re: SLSB failover without cluster
              pferraro

              The load balancing behavior is the same for both mechanisms.

              • 4. Re: Re: SLSB failover without cluster
                pmm

                We have trouble getting this to work. We are testing a two server set up. What works is having only one server running when starting the client. What we can't get to work is having two servers running when starting the client and then stopping one server. In this case we get the following exception

                java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:acme-ear, moduleName:acme-module, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@2bf94853

                at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:736)

                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:254)

                at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:199)

                at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:182)

                at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:145)

                at com.sun.proxy.$Proxy25.someMethod(Unknown Source)

                This is our client configuration (credentials missing), we're using TLS

                endpoint.name=acme-ejb-client

                jboss.ejb.client.properties.skip.classloader.scan=true

                remote.connection.connection1.connect.eager=false

                remote.connection.connection1.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL=10000

                remote.connection.connection1.connect.options.org.xnio.Options.KEEP_ALIVE=true

                remote.connection.connection1.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

                remote.connection.connection1.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true

                remote.connection.connection1.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false

                remote.connection.connection1.connect.options.org.xnio.Options.SSL_STARTTLS=true

                remote.connection.connection1.connect.timeout=30000

                remote.connection.connection1.host=acme1

                remote.connection.connection1.port=7860

                remote.connection.connection2.connect.eager=false

                remote.connection.connection2.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL=10000

                remote.connection.connection2.connect.options.org.xnio.Options.KEEP_ALIVE=true

                remote.connection.connection2.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

                remote.connection.connection2.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true

                remote.connection.connection2.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false

                remote.connection.connection2.connect.options.org.xnio.Options.SSL_STARTTLS=true

                remote.connection.connection2.connect.timeout=30000

                remote.connection.connection2.host=acme2

                remote.connection.connection2.port=7820

                remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=true

                remote.connections=connection1,connection2

                • 5. Re: SLSB failover without cluster
                  jaikiran

                  Please enable TRACE level logs on org.jboss.ejb.client package on client and post the output here.

                  • 6. Re: Re: SLSB failover without cluster
                    pmm

                    This was a somewhat embarrassing error on our side. We set the jboss.node.name property to the same value on both hosts. Once we set it to different values the feature works as advertised.

                    1 of 1 people found this helpful