Clustered Stateless Session bean

[rzvikas]

I am trying to understand how clustering works with JBOSS 7.1

As per the JBOSS documentation I have read...Remote client can have  any one server entry into jboss-ejb-client.properties....from the list of cluster instances.But it is not working....Could someone please take a look at it.

Here is my configuration, When I bring down the server instance 1(4447) , then I can not send request to instace 2 anymore...I get this exception (Exception in thread "main" java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:sample,distinctname:])

On the server I have @Clustered / @Stateless simple java bean

Server Instance 1 :

----------------------------

standalone.bat -server-config=standalone-ha.xml -Djboss.server.base.dir=instance1 -Djboss.node.name=instance1

Server Instance 2 :

----------------------------

standalone.bat -server-config=standalone-ha.xml -Djboss.socket.binding.port-offset=200 -Djboss.node.name=instance2  -Djboss.server.base.dir=instance2

Client Configuration :

------------------------------

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

remote.connections=default

remote.connection.default.host=localhost

remote.connection.default.port=4447

remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

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

remote.clusters=ejb

# Connection configuration(s) for the "ejb" cluster (these are just random examples. You might have to add username and password

# or callbackhandler depending on the security configuration(s) of these cluster node servers.

remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.cluster.ejb.connect.options.org.xnio.Options.SSL_ENABLED=false

[wdfink]

What have you deployed? Is the SLSB deployed on both notes?

How your code looks like?

Also there is a bug regarding the SLSB LB see this Jira.

[jaikiran]

Which exact AS7 version is this? Are the client and the server(s) on the same machine? Like Wolf says, you'll have to use the latest nightly build (post 7.1.1.Final) which contains a fix to @Clustered @Stateless handling.

[rzvikas]

Jaikiran, I have tried the same application on JBOSS eap 6.0.Beta2, JBOSS 7.1.1.1.Final and yesterday I downloaded code and build locally version 7.1.2

my Jboss structure is like this :

<JBOSS_HOME>

       <instance1> // Copy of standalone

          <deployments>

               sample.jar

       <instance2> // Copy of standalone

          <deployments>

               sample.jar

Wolf, I have deployed simple SLSB given below on both the nodes

StateHolder.java

@Remote

public interface StateHolder {

     public int getId();

}

StateHolderBean.java

@Clustered

public @Stateless class StateHolderBean implements StateHolder {

     private static int id = 1;

@Override

public int  getId() {

);

return id++;

} 　

}

     System.out.println(" Server side"

[wdfink]

How your client looks like?

As you say "When I bring down the server instance 1(4447) , then I can not send request to instace 2 anymore"

is your client restarted after instance1 is down? Because from your client-properties you have only one node and the context is uploaded if the client is connected to this instance and it only knows instance2 from this point.

[rzvikas]

Two nodes on the server on the same machine and running on different port offset.

Client is standalone java application on the same machine. Do you mean, do I need to specify all server port in the jboss-ebb-client.properties. Since client is making call to a stateless session bean . Client is disconnected after making a call.

[wdfink]

If the JBoss instances form a cluster this context will provided to a client after the first ejb call.

But if you stop the JVM this information is lost and you need to make a ejb-call to the servers of the ejb-client.properties.

Also this JIRA AS7-4223 might related to your problem, but it should be solved if you build the 7.1.2 from git

[rzvikas]

Thanks Guys for your reply. Appreciate it.

[vatsanm]

hi,

I have the same problem with a twist.  I am using a EJB client running on a different JB7.1.1 instance and the EJB servers are on a clustered environment.  Based on the conversation above, how do I configure the remot.clusters in this case (I'm using standalong-ha.xml ).  Can you point me in the reight direction please?

[wdfink]

Vatsan,

as this thread might be outdated and your issue is a bit different could you open a new thread and describe what and how you configure the servers and deploy the application?

[vatsanm]

Wolf-Dieter,

    Moved it to https://community.jboss.org/message/757302#757302

[morphy]

as far as I know, you have to configure every cluster node in the client properties, have you tried:

remote.connections=svr1,svr2

remote.connection.svr1.host=localhost

remote.connection.svr1.port=4447

remote.connection.svr1.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

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

remote.connection.svr2.host=localhost

remote.connection.svr2.port=4647

remote.connection.svr2.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

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

?

I have no issues and the client balances when both alive and keeps calling the live server on failure

[vatsanm]

Ricardo,

  The issue happens when the EJB srevers are clustered and also the client is running under a 3rd JB instance.  You config above is for standalone client. The config for a EJB client nder JB is similar, but I wanted to see how to configure the cluster itself and not just the individual instances.  I got it to work like you have it for a standalone client. 

[wdfink]

@Riccardo

If you have a cluster with a correct configuration and clustered applications it will be enough to have one connection in the client.properties.

Other cluster member will be pushed from this server asynchronous.

For failover it might be good to have more than one