Load balancing for singletons / distinct singleton election policies for specific singletons (JBoss EAP 7.3.10))

60 views
Skip to first unread message

DocSivia

unread,
Sep 14, 2022, 4:43:30 PMSep 14
to WildFly
Hi everyone,

I am currently running a multi-node cluster, includes quite a few singleton MDBs, amount continously increasing as I develop.
I noticed all of them are always running on the same node, changing singleton election policies always effected every singleton. Im foreseeing load balancing issues in the very near future and would like to split this 1 whole group onto more nodes.

Is it possible to to apply singleton election policies only to a specific subset of singletons? Are there other (better) ways of achieving the same goal?

Any help is more than welcome!

Paul Ferraro

unread,
Sep 15, 2022, 8:46:09 AMSep 15
to WildFly
Unfortunately no, as this feature was implemented somewhat crudely, with server-level granularity (i.e. all MDBs in the cluster will run on the same cluster member), rather than per-MDB, or even per-application, granularity.

krysiu

unread,
Nov 19, 2022, 1:33:10 PM (7 days ago) Nov 19
to WildFly
But does this election system utilize Wildfly's singleton subsystem and if yes then does it simply use "default" policy of this subsystem? My goal is to have guarantee that messages are processed by MDB that is on the same node as some other cluster-singleton bean that is activated with respect to some singleton policy (i.e. I'm using org.jboss.msc.Service) ?

Paul Ferraro

unread,
Nov 21, 2022, 9:58:15 AM (5 days ago) Nov 21
to WildFly
On Saturday, November 19, 2022 at 1:33:10 PM UTC-5 kry...@gmail.com wrote:
But does this election system utilize Wildfly's singleton subsystem

Yes.
 
and if yes then does it simply use "default" policy of this subsystem?

Yes.
 
My goal is to have guarantee that messages are processed by MDB that is on the same node as some other cluster-singleton bean that is activated with respect to some singleton policy (i.e. I'm using org.jboss.msc.Service) ?

So long as your singleton service is installed using the default policy on every cluster member as your MDBs, then the singleton election results will be the same.
However, since these are separate singleton service installations, the exact timing of the service start/stop for each service will not be precise - thus there might be a very short period of time where one service is not yet stopped while the other has already started.

You can improve the timing of this, such that there is no time where your singleton service is running on a different cluster member than a singleton MDB, by piggy-backing your singleton service on the singleton MDB mechanism itself.  This way your service starts after the singleton MDB is started, and stops before the singleton MDB stops on any given cluster member.
e.g.
ServiceTarget target = ...;
ServiceName name = ...;
Service service = ...;
target.addService(name).setInstance(service)
        .requires(ServiceName.parse("org.wildfly.ejb3.clustered.singleton.barrier")) // Piggy back on singleton MDB mechanism
        .setInitialMode(ServiceController.Mode.PASSIVE)  // Ensures this service starts when required service starts, and stops before required service stops
        .install();

Paul

krysiu

unread,
Nov 22, 2022, 2:29:42 PM (4 days ago) Nov 22
to WildFly
Thanks for the answer. It's a pity, however, that I can't associate these services the other way round i.e. the MDB can process messages only when the other HA bean is active.

krysiu

unread,
Nov 23, 2022, 4:29:27 AM (3 days ago) Nov 23
to WildFly
1. This org.wildfly.ejb3.clustered.singleton.barrier wasn't good as I ended up with bean active on both nodes. Changed to org.wildfly.ejb3.clustered.singleton and looks ok.
2. My code is a bit different:
ServiceBuilder< ? > serviceBuilder = serviceContainer.addService( SERVICE_NAME )
.setInstance( this )
.setInitialMode( ServiceController.Mode.PASSIVE );
Supplier< Object > objectSupplier = serviceBuilder.requires( EJB3_SINGLETON );
ServiceController<?> serviceController = serviceBuilder.install();
This objectSupplier variable is not used, am I doing this correctly? I've checked and both beans are on the same node.
3. In my logs I can find:
INFO (MSC service thread 1-8) I am a master
INFO (MSC service thread 1-2) WFLYEJB0475: MDB delivery started: myserver.ear,MySingletonMDB
So HA bean starts before MDB delivery but this most likely is a coincidence. Nevertheless if I handle a message in MDB and can't find active HA singleton I can throw exception and message will be redelivered soon. Or I can wait for HA bean with Thread.sleep ;)

Paul Ferraro

unread,
Nov 24, 2022, 12:41:25 PM (2 days ago) Nov 24
to WildFly
On Wednesday, November 23, 2022 at 4:29:27 AM UTC-5 kry...@gmail.com wrote:
1. This org.wildfly.ejb3.clustered.singleton.barrier wasn't good as I ended up with bean active on both nodes. Changed to org.wildfly.ejb3.clustered.singleton and looks ok.


2. My code is a bit different:
ServiceBuilder< ? > serviceBuilder = serviceContainer.addService( SERVICE_NAME )
.setInstance( this )
.setInitialMode( ServiceController.Mode.PASSIVE );
Supplier< Object > objectSupplier = serviceBuilder.requires( EJB3_SINGLETON );
ServiceController<?> serviceController = serviceBuilder.install();
This objectSupplier variable is not used, am I doing this correctly? I've checked and both beans are on the same node.

Yes - this looks correct.  That service does not provide a value (e.g. Supplier<Void>), so you can ignore this.
 
3. In my logs I can find:
INFO (MSC service thread 1-8) I am a master
INFO (MSC service thread 1-2) WFLYEJB0475: MDB delivery started: myserver.ear,MySingletonMDB
So HA bean starts before MDB delivery but this most likely is a coincidence. Nevertheless if I handle a message in MDB and can't find active HA singleton I can throw exception and message will be redelivered soon. Or I can wait for HA bean with Thread.sleep ;)

The MDB component will still be created first, bur your service will most likely be started before the full deployment chain completes, and almost certainly before the MDB receives its first callback - though, technically, there is no guarantee of this.
Either way, I'm glad to see that this is workable.
Reply all
Reply to author
Forward
0 new messages