How to prevent load balancing of specific EJBs in Wildfly HA profile ?

[grzegorz.lojek]

Hello,

I have a question: it is possible to prevent load balancing of some explicitly specified EJBs when Wildfly is running in standalone-ha configuration?

While doing some checks on Wildfly HA & clustering capabilities I made simple experiment:

1. Started two instances of Wildfly 8.0.0.Final with standalone-ha profile, running on the same machine with different port offsets, so that instance 1 listens on port 8180, and instance 2 on port 8280.
2. Deployed statefull session bean into both instances. This bean was not annotated with @Clustered (btw, seems like @Cluster annotation is depreciated in Wildfly 8).
3. Run simple standalone application that looks up for a bean always on a first instance (port 8180) for 10 times.

I noticed that my 10 beans have been balanced between two instances. It seems like when Wildfly is started with HA configuration (JGroups subsystem is active plus some changes in ejb cache) I don't need to do anything else to have load balancing on EJB, which is great.

However, I would like to have an exception for some specific beans: they need always to be running on specific instance (intentionally "break" HA).

It is possible? How can I do this?

Thanks!

[rhusar]

(btw, seems like @Cluster annotation is depreciated in Wildfly 8).

That's correct.

You can read about all changes here: Clustering Changes in WildFly 8

However, I would like to have an exception for some specific beans: they need always to be running on specific instance (intentionally "break" HA).

It is possible? How can I do this?

You can define the bean as @Stateful(passivationCapable=false), which means that since it cannot be passivated, it cannot be clustered.

http://docs.oracle.com/javaee/7/api/javax/ejb/Stateful.html#passivationCapable()

I don't need to do anything else to have load balancing on EJB, which is great.

Right, that's the default. Cool.

[grzegorz.lojek]

> You can define the bean as @Stateful(passivationCapable=false), which means that since it cannot be passivated, it cannot be clustered.

I tried with passivationCapable=false, but this bean is still balanced between two instances.

Any idea what elase I could try?

Regards

  Grzegorz

[pferraro]

> I tried with passivationCapable=false, but this bean is still balanced between two instances.

Any idea what elase I could try?

Are you certain?  We have tests that validate that passivation-incapable SFSBs are not clustered, and that non-clustered SFSBs are not load balanced.

[grzegorz.lojek]

Hi Paul,

> We have tests that validate that passivation-incapable SFSBs are not clustered, and that non-clustered SFSBs are not load balanced.

Are you talking about StatefulFailoverTestCase and StatefulTimeoutTestCase? If so, then these tests don't check what I meant.

In my experiment I created (for 10 times) a bean using scoped client context that called method returning result of ManagementFactory.getRuntimeMXBean().getName(). This method in most implementations of JVM returns PID@machineName, so it was a way (not super-elegant) of checking which JVM took care of the bean.

When I started two instances with standalone.xml, the result was always 10 times the same value (containing PID of the server where I connected).

When I started two instances with standalone-ha.xml configuration I always got two different values in various proportions (5/5, 7/3, 8/2 etc), no matter whether passivationCapable was false or true.

If you like I can send you Arquillian test cases for this - all you have to do it to put them into directory ./testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful of your wildfly project (I tested them on tag 8.0.0.Final) and run them as other wildfly integration tests.

Regards

Grzegorz

[pferraro]

Can I ask a stupid question?  When you say that the requests are load balanced, do you mean that multiple invocations for the *same* bean instance (i.e. one session) are load balanced?  or that invocations for multiple instances (i.e. multiple sessions) of the same bean go to different nodes?

If you mean the former, then that's a bug - although I'd be surprised since the RemoteFailoverTestCase.testStatefulFailover() test case validates this scenario.

If you mean the latter, then that's not a bug.  While SFSBs can be created on any node (the default selection of which is random), once created, subsequent invocations will retain affinity to the node that "owns" the session.  To assert more control over the load balancing of SFSB creation, you should use a custom ClusterNodeSelector, configured via the remote.cluster.ejb.clusternode.selector client property.

[grzegorz.lojek]

Right, I should be more specific about this.

I meant the latter, i.e. invocations for multiple sessions, thus - this is not a defect

So, I will have to play with ClusterNodeSelector. I guess for my case I should always return the node I'm expecting to connect, right ?

And related question: as far as I remember, the default implementation of ClusterNodeSelector chooses node randomly.

Is there any way of choosing a node that have smallest load (whatever it is defined)?

The only method in ClusterNodeSelector looks like this:

     String selectNode(final String clusterName, final String[] connectedNodes, final String[] totalAvailableNodes)

so I don't see here any additional information about the nodes other that their names. I would imagine if there were some additional context information that could be populated on server side, then client could choose the one that is most suitable.

Thanks!

[pferraro]

So, I will have to play with ClusterNodeSelector. I guess for my case I should always return the node I'm expecting to connect, right ?

Correct.

Is there any way of choosing a node that have smallest load (whatever it is defined)?

Not currently.  You can make the ClusterNodeSelector stateful, and record the result of previous selections to improve the fairness of your balancing, but that's not the same as what you're asking.  We'd need to enhance the client to support this.

[grzegorz.lojek]

Thank you all for help