Multi-Active Application Servers

Connexion v26 moves the application-server architecture from an active-passive model to a multi-active model. Instead of one server doing all message-processing work while another waits as a standby, multiple Connexion application servers can run at the same time.

Channels are distributed by owning tab or group. As application servers join, leave, or are taken offline, Connexion can rebalance that work across the eligible application-server pool.

Multi-active means that many application servers can own different work concurrently; it does not mean that the same channel executes concurrently on multiple servers.

From standby to shared work

Static and dynamic clusters

Multi-active supports two distinct cluster models. The model determines how application-server identity and placement affinity are interpreted.

A deployment operates as one cluster type at a time. The same placement-affinity metadata therefore has one unambiguous meaning in the running cluster: a server preference in a static cluster, or a workload-cohort key in a dynamic cluster.

Cluster view

The Servers view represents the cluster as a pool of application servers. Each tile is a real Connexion application-server identity with a heartbeat, runtime endpoint, owned work, and operational state.

Three active Kubernetes application servers share one configuration database. The placement tree shows how tabs are distributed across the pool, while cluster health and scaling information appear beside it.

This view answers the first operational questions:

• Which application servers are currently part of the cluster?

• Which servers are Ready, disabled, stale, starting, or stopping?

• Which tabs and channel groups are currently owned by each server?

• How much work is running on each server?

• Is Kubernetes or another platform currently changing the desired capacity?

Automatic rebalancing as servers join and leave

Connexion reacts to cluster-membership changes automatically. Infrastructure supplies or removes compute capacity; Connexion turns the resulting membership into safe application-level placement.

When an application server joins

1. The new runtime starts and establishes its application-server identity.

2. Health and readiness checks confirm that it can accept work.

3. Connexion adds it to the eligible placement pool.

4. Placement is recalculated across the expanded pool.

5. Tabs or channel groups selected for movement stop on their previous owner and start on the new owner.

6. Registered inbound routes are republished when placement changes.

When an application server leaves

A server can leave because it is deliberately taken offline, an elastic platform reduces capacity, maintenance drains the node, or the runtime becomes unhealthy.

1. The server becomes ineligible for new placement.

2. Work owned by that server is reassigned to eligible capacity.

3. Affected channel groups stop on the old owner and restart on their new owner.

4. Static-server preferences remain recorded so they can be honored again when appropriate.

5. Dynamic affinity cohorts remain together while moving to a surviving server.

6. Inbound routes are reconciled to the new channel owners.

Dynamic platforms normally use a stabilization or drain interval so Connexion has time to release and redistribute work before the runtime disappears. In the Kubernetes validation, the deployment returned from six Ready pods to its configured one-pod baseline after load stopped. The AWS Auto Scaling Group validation demonstrated the equivalent expansion and contraction with EC2 application servers.

See Kubernetes: Dynamic Scaling and Cloud Dynamic Scaling & Integration for the platform-specific scaling policies, lifecycle hooks, and performance runs.

Rebalance policies

A rebalance policy determines how Connexion estimates the amount of work assigned to each application server. The resulting score is used to generate placement proposals; work is moved only when the projected placement improves the distribution across eligible servers. Affinity cohorts remain atomic regardless of the selected policy.

How configured weights work

Weights are relative placement costs, not CPU percentages or resource limits. A workload with weight 20 is treated as twice the placement cost of a workload with weight 10.

• A tab without an explicit weight contributes a default weight of 1 when it contains undeleted channels.

• A group without an explicit weight inherits the sum of its eligible child-tab weights.

• An explicit group weight overrides the child-tab total.

• When tabs or groups share placement affinity, their weights are combined and the complete cohort moves as one unit.

For example, if one server has workloads totalling 35 and another totals 10, moving a weight-10 unit produces scores of 25 and 20. That is a better distribution than 35 and 10. Connexion evaluates movable units sequentially and proposes a move only when it reduces the overall score imbalance, so the result is intentionally practical rather than a promise of mathematically perfect bin packing.

How process-metric scoring works

Process Metrics Balanced maintains placement statistics for each execution group on each application server. Process metrics are sampled approximately every 20 seconds.

• CPU pressure uses a five-minute exponential moving average so normal short variation does not cause constant movement.

• A one-minute rolling CPU maximum also contributes to the score so sustained bursts are not hidden by the longer average.

• Memory pressure uses the process's latest working-set value; memory is not averaged.

• The placement score is the greater of the CPU average or half of the recent CPU maximum, plus one memory-pressure point for each 256 MiB of working set.

• Stopped processes, newly started processes, and processes with stale metrics are excluded from movement proposals.

The CPU accumulator and short sample queue are held in application-server memory rather than stored as a historical time series. They restart when the service restarts or process-metric scoring is disabled. A minimum process-uptime requirement allows the score to warm up before an execution group becomes eligible to move.

The configured mechanism can drive automatic rebalancing when membership changes in a dynamic cluster. Operators can also use Manual Rebalance to preview the resulting moves, inspect current and target scores, adjust proposed hosts, and choose which moves to apply.

Placement in static clusters

Static clusters have stable application-server identities. An operator can therefore move work to a particular server and optionally record that server as the preferred owner.

A preferred application server is a placement preference rather than an availability constraint. If the preferred server is offline, stale, draining, or otherwise unavailable, the channel group can run elsewhere so processing continues. The preference remains available for later placement or failback when that server becomes eligible again.

The bulk transfer dialog supports a larger placement change. Operators can choose a target server, select multiple tabs or groups, and filter by current application server or repository.

Typical static-placement uses include:

• moving work away from a server before maintenance;

• keeping an interface close to a server-specific network dependency;

• isolating a high-throughput workload on dedicated capacity; and

• recording a preferred owner while still permitting availability-driven failover.

Placement affinity in dynamic clusters

Dynamic servers are disposable capacity. Pinning a workload to a pod or Auto Scaling Group instance would be misleading because that runtime may soon disappear.

Instead, dynamic-cluster affinity expresses a relationship between workloads: these tabs or groups should stay together. Matching affinity values form a cohort. Connexion places and moves the complete cohort as one unit on an eligible application server.

This provides a simple way to keep related work together when it shares:

• ordering or sequencing assumptions;

• local scratch or cache behavior;

• related inbound routes;

• an operational dependency; or

• a desire to scale and rebalance as one unit.

Manual Rebalance treats affinity 61f745ad as one atomic three-tab movement candidate. The preview proposes moving the complete cohort from 10.244.0.112 to 10.244.0.111, improving the placement score from 5.0 to 3.0 while preserving affinity. The per-server targets show all three tabs moving together.

The preview shows:

• the current and proposed application server;

• the placement weight being moved;

• the reason and score change for each proposal;

• the effect on per-server group and tab counts; and

• the current and target placement scores.

Operators can review the proposals, deselect individual moves, or choose another proposed host before applying the selected changes.

In a static cluster, pinning can influence whether a proposal is eligible and whether a preferred owner should be retained or changed. In a dynamic cluster, an affinity cohort is movable by definition, but all members of that cohort are expanded into one atomic movement candidate.

Applying a rebalance updates ownership in the configuration database and refreshes the previous and target runtimes. The old owner relinquishes the work before the new owner starts it, preserving the single-owner execution rule. Any registered inbound routes are then reconciled to the new owner.

After applying the preview, all three tabs in affinity 61f745ad are placed together on 10.244.0.111. The shared key remains visible and Remove affinity is enabled, confirming that the cohort moved as one unit and retained its affinity.

App server UI

The selected Kubernetes application server shows runtime identity, heartbeat, operating system, owned tabs, pod information, and the shared PostgreSQL configuration database.

Useful diagnostic context includes:

• application-server heartbeat and stale state;

• current ownership and static preferred ownership;

• dynamic affinity membership;

• running execution groups and process state;

• published inbound routes and reconciliation state;

• scaling-provider state and desired capacity; and

• database and runtime diagnostics.

Relationship to dynamic inbound routing

Multi-active placement changes where an inbound channel runs. Dynamic inbound routing keeps the external endpoint stable while updating its backend destination.

When a channel moves because of a manual transfer, automatic rebalance, scale-out, scale-in, or recovery, Connexion republishes the route to the application server that now owns the channel. External systems continue using the same frontend address and port.

See Dynamic Inbound Routing for supported router providers, route registration, reconciliation, and operational diagnostics.

Related pages

• Kubernetes: Dynamic Scaling

• Kubernetes and Helm: Deployment & Management

• Cloud Dynamic Scaling & Integration

• Dynamic Inbound Routing