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