Deployment and Clustering

The scenario is the Bookshelf application of the other pages, with a few additions that exist only to watch state move:

Both nodes run the same exploded WAR on ports 8760 and 8761; the proxy listens on 8762. In the tables below, "counter" is the value of the view bean’s counter after three Save postbacks on node A and one more on node B, so 4 means that node B continued with the same bean instance node A used, and 1 means that it found an older or a new one.

A Faces application is a standard WAR: WEB-INF/classes, WEB-INF/lib, the XHTML views and resources at the root (or under src/main/webapp in a Maven project), WEB-INF/web.xml and WEB-INF/beans.xml. What decides the contents is who provides Faces. On a Jakarta EE server (GlassFish, WildFly, Payara, Open Liberty, TomEE) the server has the Faces implementation and Weld or OpenWebBeans, and the WAR holds only the application and the compile-time API as provided. On a plain servlet container such as Tomcat the WAR carries the implementation, a CDI container and the annotations API itself. One pom.xml with a profile covers both, and both were built:

Source: Apache Maven WAR Plugin: Usage and Apache Maven: Configuring for Reproducible Builds

The default build produced a WAR of 22,519 bytes with no libraries in WEB-INF/lib. With -Ptomcat it produced 6.1 MB containing jakarta.faces-4.1.17.jar, weld-servlet-shaded-6.0.4.Final.jar and jakarta.annotation-api-3.0.0.jar. Which libraries a given server needs, and what happens when the WAR carries a second implementation that the server also has, is the subject of Jakarta EE Servers (Tomcat and Weld covers the case where you bring the implementation); the short version observed there is that a WAR with its own Faces implementation can clash with the one the server provides, so decide per target and keep the dependency scope honest.

Reproducible builds. A deployment pipeline is easier to trust when two builds of the same commit give the same file. The property project.build.outputTimestamp in the POM above fixes the timestamps in the archive; building the Tomcat variant twice, with a clean and a pause in between, produced the same SHA-256 (18794ab4... in the run) both times. The benefit for operations is that the checksum of the WAR identifies the build and a changed checksum means changed content.

web.xml. A WAR no longer needs one, because Faces 4 registers FacesServlet itself, but a production WAR usually has one for the parts that are decisions of the deployment: the project stage, where the view state lives, the session cookie, the error pages and <distributable/>. The file used for every run in the clustering sections is below; the elements are explained in the sections that use them. It validates against the Servlet 6.1 schema (web-app_6_1.xsd).

Source: Jakarta Servlet 6.1 specification and Jakarta Faces 4.1 specification, 11.1.3 Application Configuration Parameters

Two details of that file are worth a sentence each. <distributable/> is the application’s promise that it can be spread over several JVMs: every session attribute must then be serialisable, and the container is free to replicate or persist sessions. The <session-config> makes the session cookie HttpOnly and Secure; when the nodes sit behind a proxy that ends TLS, the Secure flag is set from the configuration and does not depend on the proxy (The Reverse Proxy in Front of the Nodes shows the other half). The beans.xml is the one every Faces application has:

Source: Jakarta EE Tutorial: Configuring Jakarta Faces Applications

On Tomcat the application needs nothing else in web.xml: the WAR built with -Ptomcat, unpacked and run on the two-node cluster without an explicit Weld listener, served pages and replicated sessions on both nodes. The context root is the name of the WAR (bookshelf.war serves /bookshelf; a WAR called ROOT.war serves /).

jakarta.faces.PROJECT_STAGE is Production when it is absent, and a mistyped value is also Production, so the setting that matters in an environment is the one that must be absent from it: nothing may switch a server that real users reach to Development. How the stage is resolved (a JNDI entry beats the context parameter), what each stage changes and how to select it per environment is on the project stages section of the configuration page; the cost of running anything else is measured on the performance page. For a deployment the checklist is short:

The container’s own error page. A request that fails without an error-page mapping gets the server’s default report. On Tomcat 11.0.26 that report shows the exception message and a stack trace. The run that follows posted a page rendered by node A to node B without a session (the cluster-failure case of the next sections), which ends in a ViewExpiredException:

The valve is one element in the <Host> of server.xml:

Source: Apache Tomcat 11: Error Report Valve

Faces' own error handling (the error-page elements, an ExceptionHandler) answers first for exceptions that reach Faces; the valve is the last line of defence for everything else. Other servers have their equivalents; the point is that a stack trace and a server version are information for the attacker and for nobody else.

A container image puts the WAR, the server and its configuration in one artifact. The Docker pages of this guide cover the mechanics (Dockerfile fundamentals, Java images and image best practices); this section is about what is specific to a Faces WAR on three servers. The image names and tags below were checked against the registries on 2026-10-08, and the paths and users against the images' own Dockerfiles. The images were not built, because no Docker daemon ran in the scratch environment.

Tomcat. The official image is tomcat:11.0.26-jdk21-temurin-noble (tags with jre instead of jdk and with Java 17 and 25 exist). Its webapps directory is empty, Tomcat runs as root unless told otherwise, and the console receives the log. A WAR copied to /usr/local/tomcat/webapps is deployed at start:

Source: Docker Official Image: tomcat

WildFly. The image is quay.io/wildfly/wildfly:41.0.1.Final-jdk21 (the old jboss/wildfly image on Docker Hub is no longer updated). It runs as the jboss user, starts standalone.sh -b 0.0.0.0, and the deployment scanner of the default configuration deploys what is in /opt/jboss/wildfly/standalone/deployments/. The default standalone.xml has no clustering; the high-availability configuration is standalone-ha.xml, selected with --server-config:

Source: WildFly container image repository and WildFly 41 Administration Guide

Payara. payara/server-full:7.2026.9 exists (a -jdk25 variant too) and runs the server’s JVM as the payara user. The entry point deploys every WAR it finds in /opt/payara/deployments after the domain starts, and the image configures the server log to go to the console. Its Dockerfile sets the administration password to a well-known literal at build time, so the administration port (4848) and the debug port (9009) must never be published; only 8080 and 8181 are the application’s:

Source: Docker Hub: payara/server-full and Payara image sources

What every image has in common is how it learns its secrets. The client-state keys of Client State Saving Across Nodes, a database password or an OpenID Connect client secret reach the container as environment variables or mounted files, from a secret store, never as a line of the Dockerfile and never as a file in the WAR (the security page lists the rules). A value written in a Dockerfile is in every layer of the image and in its history.

Two nodes behind a proxy is the smallest cluster, and Compose describes it in one file. docker compose config accepted the file below (syntax and schema; the stack was not started). The key values come from the caller’s environment or from an untracked .env file, and no key is in the file:

Source: Docker Compose documentation

On Kubernetes the same idea is a Deployment with two replicas and a Service. The parts that matter to Faces are the readiness probe (a node that is starting, or leaving, must not receive postbacks: Monitoring), the secret injected as an environment variable, a pod name as the node name, and a grace period long enough for requests in flight. This manifest parses as YAML; it was not applied, because no cluster was available:

Source: Kubernetes: Deployments and Kubernetes: Configure Liveness, Readiness and Startup Probes

A Service load-balances per connection, not per session, so the manifest gives Faces no stickiness at all: every strategy of the sections below must come from the application (replication, client state) or from the ingress or gateway in front of the Service (cookie affinity). The Kubernetes pages of this guide cover the objects: health probes and lifecycle, Services, Ingress, Gateway API, Secrets and deployment strategies.

Production traffic reaches a Faces application through a reverse proxy or load balancer that ends TLS, spreads the requests, and (sometimes) sends a session back to the node that holds it. The application server sees plain HTTP from the proxy’s address. Four things about that arrangement concern Faces.

1. The scheme and the client address. The proxy tells the node what the browser used with X-Forwarded-Proto, and the node must be told to believe it, but only from the proxy. On Tomcat that is the RemoteIpValve. The run below sent the same request with X-Forwarded-Proto: https, once to a node without the valve and once to a node with it; the Secure flag of the session cookie that Tomcat created is the visible difference (the redirect of a faces-redirect=true navigation was the relative /bookshelf/draft.xhtml in both runs, so the redirect itself does not depend on the scheme):

Source: Apache Tomcat 11: Remote IP Valve

The internalProxies expression lists the addresses whose forwarded headers are trusted; anything else is ignored. The proxy, for its part, must overwrite the forwarded headers rather than append to what the client sent, otherwise a client chooses its own address. The OmniFaces page shows what that costs: a rate limit keyed on the forwarded address was bypassed by five requests that each sent a different X-Forwarded-For. The cookie flag is the cheap protection that works either way, which is why the web.xml above also sets <secure>true</secure> itself.

2. Where a request goes. This is the load-balancing decision of Sticky Sessions. The following httpd configuration was run with the two nodes: it routes by the route suffix that Tomcat adds to the session id.

Source: Apache HTTP Server 2.4: mod_proxy_balancer and Apache Tomcat 11: Clustering and load balancing with Apache HTTP Server

3. WebSockets. f:websocket opens a long-lived connection to /jakarta.faces.push/<channel>. The proxy must pass the upgrade and keep an idle connection open longer than its own timeout. In httpd that is mod_proxy_wstunnel (a ProxyPass with a ws:// URL for the push path); in nginx it is the Upgrade and Connection headers and a raised proxy_read_timeout, whose default is 60 seconds. The nginx file below follows its documentation and was not run (no nginx was available); it also shows the open-source sticky cookie directive, which exists since nginx 1.27.3. A message sent to a channel reaches the sockets of one node only: see State That Stays on One Node and the WebSocket page.

Source: nginx: WebSocket proxying and nginx: ngx_http_upstream_module, sticky

4. Caching. A shared cache in front of Faces must not store the pages, which are per user and carry a state token. The resources served from /jakarta.faces.resource/ can be cached according to the rules of the resource handling page. Neither httpd (with mod_cache not loaded) nor nginx (without proxy_cache) caches anything in the configurations above, which is the safe default.

The cloud providers' load balancers (see the AWS, Azure and Google Cloud sections of this guide) offer cookie-based affinity with their own cookie, and the Kubernetes ingress and gateway objects have their own affinity settings; the Faces rule is the same everywhere: if a strategy needs the postback to return to the node that rendered the page, something in front of the nodes must make it so.

The view state is what Faces needs to restore a page at the next postback: the component tree’s changes, and with them the identity of the view-scoped beans. The state saving page explains the mechanism; for a cluster it comes down to one question with three answers, drawn in the figure.

Server state saving (the default of both implementations) keeps the state in the HTTP session of the node that rendered the page and sends only a token. Client state saving sends the whole state, encrypted and signed, in the jakarta.faces.ViewState field and keeps nothing on the server. A stateless view (f:view transient="true") saves nothing and sends the word stateless. Combined with the two ways of moving a request between nodes, the strategies are:

Source: Jakarta Faces 4.1 specification, 7.8.2 State Saving Alternatives and Implications

The rest of the page tests each box of that diagram: sticky sessions in Sticky Sessions, replication in Session Replication, the rules for beans in Serialisable Beans and Components and Changes Made in Place Are Not Replicated, client state in Client State Saving Across Nodes, and the surprise of the last box in @ViewScoped in a Cluster.

The observed behaviour of the three strategies, on the same two nodes, is the baseline for everything that follows. A page is rendered by node A and three Save postbacks run there; the next postback goes to node B with the state A produced last. The rows differ in what node B has:

Source: Jakarta EE Tutorial: To Specify Where State Is Saved

A sticky (or affinity) load balancer sends every request of a session to the node that created it. The balancer needs a key: Tomcat appends the jvmRoute of its <Engine> to the session id (JSESSIONID=<id>.node-a), and httpd’s stickysession=JSESSIONID|jsessionid reads the suffix and picks the member with route=node-a. nginx’s sticky cookie sets a cookie of its own. For Tomcat the only server-side step is the attribute:

Source: Apache Tomcat 11: The Engine Container

Behind the httpd configuration of The Reverse Proxy in Front of the Nodes, one client made six requests and all of them reached the same node (X-Node: node-b in that run); a second batch of new clients was distributed by the balancer’s algorithm (2 and 6 of 8 in the small run). Sticky sessions are the cheapest strategy, and everything in Faces works with them: server state, @ViewScoped, the flash, the session and application beans. (Weld enforces the Serializable rule of the passivating scopes at deployment in any case; see the scopes page.) Their limits are the limits of a node:

Use sticky sessions as the first line (they save the network traffic of replication) and add replication or client state when losing a session is not acceptable.

Session replication copies HTTP sessions to other nodes, so that any of them can continue. The application opts in with <distributable/> (shown in the web.xml above), and the container decides how: Tomcat’s cluster with a DeltaManager (all to all) or a BackupManager (one backup per session), WildFly’s distributable-web subsystem on Infinispan, and similar mechanisms in the other servers. The Faces side has three requirements: the session must contain only serialisable objects (Serialisable Beans and Components), changes must reach the replication mechanism (Changes Made in Place Are Not Replicated), and, on Mojarra, one context parameter must be set.

Tomcat. The cluster of the experiments is the <Cluster> element below inside the <Engine>. It uses the BackupManager, a static membership of the two nodes (multicast discovery is the default of Tomcat’s cluster, but many container networks do not carry multicast), and Tomcat’s ReplicationValve to start the replication when a request ends. Node B has the same element with the roles of the addresses swapped. On separate hosts the addresses are the hosts' own.

Source: Apache Tomcat 11: Clustering/Session Replication How-To and Apache Tomcat 11: The Cluster Manager object

Tomcat’s own checklist (every session attribute Serializable, the Cluster element, <distributable/>, a jvmRoute, a load balancer in sticky mode) matches the requirements above. Two points from its documentation matter beyond the checklist: the DeltaManager replicates to every node, which the documentation does not recommend for more than about four nodes, and replication is triggered only when the session has changed by a call of setAttribute or removeAttribute, which is the source of Changes Made in Place Are Not Replicated.

The cluster traffic is session data. The channel carries serialised sessions, and with Mojarra a serialised client-state key (Client State Saving Across Nodes). Tomcat’s EncryptInterceptor encrypts the channel messages. It was run with the key taken from the environment (${CLUSTER_KEY} resolved by the EnvironmentPropertySource of Client State Saving Across Nodes): with the same key on both nodes replication worked as before; with different keys node B logged SEVERE ... EncryptInterceptor.messageReceived Failed to decrypt message with an AEADBadTagException, and node B did not get the sessions (the ViewExpiredException row again). The interceptor goes before the TcpFailureDetector in the channel:

Source: Apache Tomcat 11: The Channel Interceptor

Mojarra needs enableDistributable. Mojarra documents com.sun.faces.enableDistributable as the switch that tells it the application is distributed, so that it sets a session attribute again after every change to it, which is what triggers session replication; the default is false because the extra writes cost time. The experiment confirms the need: with <distributable/> and the Tomcat cluster but without the parameter, node B answered the postback of a replicated session with a ViewExpiredException, on server state saving. With the parameter in web.xml it restored the view and the view bean counter was 4. MyFaces' configuration reference lists no parameter with this effect, and its server state restored on node B in both runs (its limit is Changes Made in Place Are Not Replicated).

Source: Mojarra 4.1 context parameters

WildFly and the others. WildFly’s guide says a web application indicates its intention with <distributable/>, that the default session management uses SESSION granularity (all attributes in one cache entry) and that ATTRIBUTE granularity replicates only the attributes that a request added, modified, removed or mutated; the profile with the clustering subsystems is standalone-ha.xml. A WildFly, Payara or Open Liberty cluster was not run for this page, and how WildFly detects a change inside a CDI bean was not tested; read the server’s guide for the detection rules before trusting Changes Made in Place Are Not Replicated to carry over.

Source: WildFly 41 High Availability Guide

Quarkus has no session replication. The MyFaces extension documentation states that Quarkus does not support session replication, passivation or clustering (see State Saving, Sessions and Restarts on the Quarkus page, which was run on one instance only; no Quarkus cluster was run for this page). Several Quarkus instances therefore have only the two other answers of the figure: sticky sessions with server state (a node that is lost takes its sessions and every open form with it), or client state with the same encryption keys on every instance (Client State Saving Across Nodes), which survives the loss of a node but not the loss of the view-scoped beans (@ViewScoped in a Cluster). The same reasoning applies to any runtime whose sessions are not replicated; the Tomcat cluster of this page is the case where replication is available. On Spring Boot with JoinFaces (Sessions and Cookies) a clustered deployment was not run either, so the rules of this page are the starting point and have to be tested there.

Fail-over works. With the Tomcat cluster above (Mojarra, server state), node A rendered a page and ran two postbacks (counter 2); node A was stopped; the next postback, sent to node B with A’s session id, returned counter 3. Behind httpd with the sticky configuration, the same client was routed to node B by the balancer once A was down, and kept its .node-a cookie. No cookie rewrite was needed for that (Tomcat’s JvmRouteBinderValve exists to rewrite it when the balancer relies on the suffix).

Session replication, session persistence across a restart and CDI passivation have the same requirement: whatever is reachable from the session must survive ObjectOutputStream and ObjectInputStream. In a Faces application the session reaches further than the @SessionScoped beans:

The rule that makes a bean cheap and safe to move is to keep in a passivating scope only values: identifiers, strings, numbers, small immutable records. The bean below keeps the ISBNs of the reading list rather than Book objects (a graph of entities would be copied with the session at every replication) and marks the rebuildable helper transient:

Source: Jakarta CDI 4.1 specification, Passivation capable beans and Java Object Serialization Specification

A unit test finds the mistakes before the cluster does. It copies the bean through serialisation, which is what a replication does, and it checks that a bean that holds a non-serialisable field is rejected. It was run with JUnit Jupiter 6.0.3 (two tests, both passed):

Source: JUnit User Guide

The unit test finds problems in beans, not in the component state. That needs a running application: jakarta.faces.SERIALIZE_SERVER_STATE set to true makes Faces serialise the state when it saves it, so that a non-serialisable value fails on a developer’s machine instead of in the cluster (it is part of the state saving page). In the cluster the same mistake looked like this. An action put an object of a class that implements Serializable but holds an Object field into the view root’s attributes (the Leaky class of the scratch DraftBean):

Source: Jakarta Faces 4.1 API: UIViewRoot and UIComponent.getAttributes()

What each configuration did with it:

The dangerous row is the first. Nothing failed for the user on node A, the only trace is a log line of the container, and the damage is discovered when a node is lost. Alert on NotSerializableException and on replication errors in the logs of a clustered application (Logging), and keep the SERIALIZE_SERVER_STATE run in the test environment.

Serialisability is the first rule of replication, the second is when the container copies the session. Tomcat’s documentation says that data is replicated only if the session has changed by a call of setAttribute or removeAttribute. A mutation of an object that is already in the session, such as isbns.add(...) on the list inside ReadingList, is not a session change. In a Faces application that matters more than it seems, because the session holds the CDI session beans, the view maps of the @ViewScoped beans and the saved view states, and none of them are set again by your code. Weld’s bean store sets the attribute when it adds the bean instance; in the bytecode of Weld 6.0.4’s AttributeBeanStore the setAttribute calls are in the methods that add a bean and that re-attach the store, not in the access path.

The experiment: node A renders reading.xhtml (the page creates the @SessionScoped ReadingList with size 0) and three Add postbacks run on A (size 3). Then a request with the same session id goes to node B, then to A again:

The second row is the cure to use when the state is small: hold it as an immutable value in a session attribute, and change it only with setAttribute. The class below is the one that was run; it injects the HttpSession (a built-in CDI bean in a servlet container):

Source: Jakarta Servlet 6.1 API: HttpSession.setAttribute and Apache Tomcat 11: Clustering/Session Replication How-To

The third row is the cure when the beans cannot be changed (view-scoped beans, third-party beans) and the container replicates only on setAttribute: set every attribute again when the request is over. That is what Mojarra does for its own attributes with enableDistributable; the filter does it for all of them. It costs one serialisation of the whole session per request, so use it where nothing better exists, and measure. With it, MyFaces' view-scoped counter went from 1 to 4 in the table of @ViewScoped in a Cluster:

Source: Jakarta Servlet 6.1 API: Filter

The filter belongs to Tomcat-style replication. Other containers decide differently (WildFly’s guide describes mutation detection for ATTRIBUTE granularity), so test the behaviour on the server you deploy to instead of assuming either. The question to ask of any container is the one this experiment answers: change an object in place on node A, ask node B for it, and look.

Client state saving removes the view state from the server: the state is in the page, so any node can restore it, provided it can decrypt it. The state saving page describes the keys; the cluster adds one rule: the same keys on every node and across restarts, and the keys are never in the WAR. The two implementations read them differently, and Tomcat can pass an environment variable into both:

The ${...} placeholders in context.xml are replaced by Tomcat only when it is told to read the environment:

Source: Apache Tomcat 11: System properties, org.apache.tomcat.util.digester.PROPERTY_SOURCE and Apache Tomcat 11: Environment Entries

Without the property source, the literal text ${FACES_CLIENT_SECRET} becomes the key and both implementations fail closed (see the state saving page). The same documentation lists ServiceBindingPropertySource, which reads values from the files of a Kubernetes service binding; it was not run. The server must be restarted in a rolling fashion with the same key: a changed key invalidates every page already in a browser (a ViewExpiredException on the next postback), so rotate keys at a quiet time, with the old pages' expiry in mind.

The experiment used the same context file on both nodes with the same keys, and then with different keys on the two nodes. The rows are the next postback on node B; "replicated session" means B received A’s session id with A’s replicated session:

The last row, on Mojarra, surprised. The explanation is in Mojarra’s ByteArrayGuard: when a session exists, it looks for a secret key in the session attribute com.sun.faces.SK, and if there is none it stores its configured key there; the key in the session then wins. A session replicated from node A therefore carries node A’s key to node B and node B decrypts with it, whatever it was configured with. The source (Mojarra 4.1 branch, matching the bytecode of 4.1.17) is plain:

Source: Mojarra 4.1 source: ByteArrayGuard

The consequences are practical:

@ViewScoped beans are the main reason server state saving is hard to leave behind. A view-scoped bean is not part of the view state, whatever the state saving method (the state saving page checks this): the beans live in the session, in a map per view, and the view state only holds the identifier of that map. The table above shows the consequence for client state: with the same keys and no session, node B restored the page and created a new bean, and the user lost what the previous bean held (saves back to 0 and counting).

So in a cluster, an application that wants to use client state saving to avoid replicating the session still needs one of three things for its view-scoped beans: sticky routing, replication of the session (with the in-place rule of Changes Made in Place Are Not Replicated), or no @ViewScoped beans in the pages that can land on any node. The third is the stateless view of Where the View State Lives, and What the Cluster Must Provide: request-scoped beans only, the whole of the view state is the word stateless, and the postback worked on node B without a session, with different keys, on both implementations (a search form with an h:inputText, a button and a ui:repeat, state stateless). The cost is that the form must be written to rebuild everything from the request, and it is the right choice for the read-mostly pages of Bookshelf: the catalogue, the search, the book detail.

The view scope also bounds the session: Mojarra keeps up to com.sun.faces.numberOfActiveViewMaps view maps per session (25 by default; the least recently used is destroyed), MyFaces the number of views in the session. Each map is replicated with the session, so the limits are a cluster setting as well as a memory setting (scopes page, view scope limits). The OmniFaces view scope has the same passivation rule and an unload-based lifecycle (OmniFaces page).

Not everything Faces keeps lives in the session. These are the things that stay on one node, and what to do about each.

The flash. The flash carries a message or an object across a redirect (flash scope), which in a cluster means a redirect that lands on another node. A page posted a form to node A, which stored a note in the flash and redirected; the redirect target was then requested from three places:

Mojarra keeps the flash in an application-wide store (its documentation describes numberOfConcurrentFlashUsers as sizing that store) and sends a cookie to find the entry, so the entry stays on the node and replication cannot move it; MyFaces keeps it in the session. The cure on Mojarra is sticky routing at least for the redirect, or avoiding the flash for anything that matters: a confirmation can be carried in a query parameter that the target view reads with f:viewParam, or stored with the entity.

Server push. PushContext.send sends to the WebSockets connected to this JVM. A cluster needs an event bus between the nodes, and each node calls send locally. The bean below separates the two steps; the adapter that listens to the bus (a Jakarta Messaging topic, a Redis channel, a database notification) calls deliver on every node, the sender’s included. The three classes compile against Faces 4.1; the bus itself was not run (the messaging pages of this guide cover the options, for example the messaging models and patterns page):

Source: Jakarta Faces 4.1 API: PushContext and Jakarta EE Tutorial: Using Ajax with Jakarta Faces Technology

Three more things behave as node-local by design; these are reasoning from their scopes and were not run in the cluster:

A restart is a planned node failure, and the strategies of the previous sections decide what the users see:

For a rolling restart, take the node out of the rotation first so that no new sessions start there (fail its readiness probe, Monitoring, or drain it in the balancer), wait until its users have moved or the sessions have expired, stop it, start the new version and let it rejoin. With replication, a new version of the application on one node must still be able to deserialise sessions written by the old one: a bean class that changed incompatibly (a new required field, a changed serialVersionUID) fails to deserialise and the affected users get a ViewExpiredException or a lost session. Declaring serialVersionUID and adding fields instead of changing them is the discipline that makes this survivable; the ReadingList above declares one.

Two Faces details help during a rollout. Resources have version parameters in their URLs (see the resource versioning), so a browser that kept an old page can still fetch the resources that page refers to while both versions are deployed, and the error page for ViewExpiredException is what a user meets when the state is gone: write it as a way back, not as a dead end (ViewExpiredException handling).

Four signals tell whether a Faces cluster is healthy: whether each node can take traffic, which node served a request, what the session layer is doing, and how many users meet an expired view.

Readiness. A load balancer should ask a node a cheap question: no session, no Faces lifecycle and no database call, or the probe itself creates sessions and load. A servlet answers it. It sends Cache-Control: no-store so that no cache keeps an old answer:

Source: Jakarta Servlet 6.1 API: WebServlet

The servlet answered 200 ready with an X-Node header on both nodes and set no cookie. A real probe checks more (the database, a downstream service) and returns 503 when the node should leave the rotation; keep it cheap, and keep a liveness probe, which asks only whether the process is stuck, separate from readiness (the Kubernetes page on health probes explains the difference).

Which node served the request. A filter adds the node name to every response and the access log can then show it. The variable comes from the environment (NODE_NAME in the Compose and Kubernetes files above):

A Tomcat access log valve with the pattern below wrote lines with the node name and the processing time in microseconds (%D; the unit is microseconds in Tomcat 11 and the first request on a cold node took about 95 ms). The session id is deliberately not in the pattern:

Source: Apache Tomcat 11: Access Log Valve

The session layer. Tomcat exposes the session manager and the cluster through JMX. The program below attaches to a running node, starts the local management agent and prints the attributes that matter; run on node B after three new sessions, it printed activeSessions = 3, maxActive = 3, rejectedSessions = 0, expiredSessions = 0 and the class org.apache.catalina.ha.session.BackupManager for Catalina:type=Manager,host=localhost,context=/bookshelf, plus the ReplicationValve (nrOfSendRequests, totalSendTime) and the http-nio-8761 thread pool (currentThreadsBusy, currentThreadCount). A monitoring agent or a Prometheus JMX exporter reads the same MBeans; the interesting alarms are sessions that grow without bound and rejectedSessions above zero.

Source: Apache Tomcat 11: Monitoring and Managing Tomcat and Java API: VirtualMachine (attach)

Application signals. The Faces-specific number is the rate of ViewExpiredException. A slow rise after a deployment means pages from the old version meeting the new one, and a sustained rate on a replicated cluster means replication is failing (Serialisable Beans and Components) or the keys differ (Client State Saving Across Nodes). Count the exception in the handler that renders the error page (the exception handling page shows where) and export it with the metrics library of the stack, as in the Spring Boot metrics and observability page or the Kubernetes observability page.

Both implementations log through java.util.logging, which every server routes into its own log. Mojarra’s loggers are named jakarta.enterprise.resource.webcontainer.faces.<area> (the areas in 4.1.17 include application, application.view, config, context, flash, lifecycle, clientwindow, renderkit, resource, timing and the Facelets ones); MyFaces' loggers are named after its classes under org.apache.myfaces. In production the defaults are what you want, and the logger of one area is raised when a problem needs it. The Mojarra lifecycle logger at FINE in Tomcat’s logging.properties:

printed the phases of each request:

Source: Mojarra 4.1 context parameters and Apache Tomcat 11: Logging

What to log in a cluster, and what not:

Everything in this table was observed on the two Tomcat 11.0.26 nodes with Weld 6.0.4 unless it says otherwise.

Source: Mojarra 4.1 context parameters and Apache MyFaces Core 4.1: configuration tables

Source: Jakarta Faces 4.1 specification, B.1 Changes between 4.1 and 4.0, B.2 Changes between 4.0 and 3.0 and the version table of Apache Tomcat: Which version?

The eight books say little about operating a Faces application, and what they say belongs to the application server of their day.

The Faces-specific pages that this page builds on: state saving, scopes, security, configuration and project stages, exception handling, WebSocket push, Jakarta EE servers, performance and multi-window support. The section also has pages on Tomcat with Weld, Spring Boot with JoinFaces, Quarkus, persistence and services, testing, migrating to Jakarta Faces and best practices; they carry the details of those runtimes.

The general-purpose guides: Docker, Compose, Kubernetes, backend development and the load balancer pages of the AWS, Azure and Google Cloud sections.