Cluster with middleware and client in the same application server

I’ve read the chapter for application scaling at Application Scaling - CUBA Platform. Developer’s Manual

There is one configuration I miss in the documentation and that is a cluster of application servers where the web client and the middleware are combined as depicted in stage 1.

I wonder if there is anything to consider with this configuration. I’ve tried to depict it in the same style as the documentation:

This type of configuration would reduce the complexity of the deployment.

1 Like

Hi,
The scheme you are suggesting is a valid deployment scheme. Especially it’s convenient when you build single WAR.

You still need to configure interaction between middleware blocks in this case, because they will communicate information about pessimistic locks, dynamic attribute configuration cache, DB-stored config properties cache and so on.
https://doc.cuba-platform.com/manual-latest/cluster_mw_server.html

Thanks for your answer @albudarov,

I want to understand the requirement for the direct interaction (via jgroups) of the middleware blocks. As I understand it, the locks, dynamic attributes and DB-stored config properties are stored in the database and hence the other middleware blocks should receive the same data from the database.

User session shouldn’t be a problem (I know you didn’t say so, I just want to mention it) in this case, because the load balancer is sticky and the web client always talks to the same middleware (or is a single WAR, as you pointed out).

Yes, if you have web client only.
REST API clients potentially can access different nodes of the cluster (if load balancer is configured accordingly).

They are stored in the database but they are agressively cached on the server. JGroups coordination is necessary to maintain cache consistency.
E.g. cache for the configuration settings is here: com.haulmont.cuba.core.app.ConfigStorage

1 Like