Agent host lifecycle: initialize resources and drain work

Inspect failed initialization before accepting work

The opening injects initialization failure into worker-1. Seek to four seconds and select worker-1: it is failed with no active invocation. Worker-2 becomes ready and serves the remaining traffic; one replacement boots at thirty seconds and becomes ready at thirty-four. At sixty seconds, eleven of twenty requests are committed and nine were rejected; none are killed. Clear Fail initialization of worker 1 and compare the returned capacity. Then set one initial worker, keep the failure enabled and disable replacement: every arrival is rejected because no worker ever becomes eligible. A failed resource initializer must not be presented as a ready host. This browser model does not construct a Java agent or allocate real clients.

Compare graceful release with forced termination

Use Common baseline settings, seek to thirty seconds and inspect worker-1. Handling the termination signal withdraws readiness and drains the work it already owns. Its state later becomes stopped, and committed sums remain in the fictional external store. Reduce Grace period to zero with long invocations to expose killed work, then raise it to twenty. Disable Handle SIGTERM and stop admission: the host may continue taking requests until its forced deadline, so a generous grace period alone does not guarantee a clean exit. Completion at exactly the deadline wins in this deterministic model. Real resource shutdown must coordinate its own executors, client closure and durable commits. The deployment reading adds rollout and verification context; neither a rollout controller nor actual operating-system signal delivery is implemented here.

Trace ownership and actual output

Initial workers creates one to four workers, and Invocation slots per worker limits each worker to one to four simultaneous requests. Startup duration delays eligibility. Request interval schedules arrivals at one second and then regularly through forty seconds inclusive. Invocation duration holds each admitted slot through three illustrative stages: prepare, model and tool. At completion, JavaScript actually adds the request number, one and two. Seek to eight seconds after Common baseline settings and set startup to zero: request 1 has committed the sum four. Before completion its output is absent. These stage names do not represent real model or tool calls. There is no queue, retry, autoscaler, CPU contention or service-time slowdown as slots increase.

Withdraw readiness before draining

Route only to ready workers chooses the least-loaded ready worker, breaking ties by worker ID. Without it, starting or draining workers remain candidates and reject requests even when another worker could serve them. Fail initialization of worker 1 affects only that original worker. Signal worker 1 at chooses the termination time; Handle SIGTERM and stop admission changes that worker to draining. It accepts no new work and exits as soon as its current invocations finish. Grace period sets a forced-stop deadline. Without the handler, the worker stays eligible until that deadline and may admit requests that it cannot finish. Boot one replacement at signal time schedules one new worker with the same startup delay. It does not recover killed requests or replace every failed worker.

Account for every request

At every snapshot, arrivals equal admitted plus rejected. Admitted equals completed plus killed plus running. A killed request has no committed sum; completed sums remain in an external-store fixture after the owning worker exits. Reload does not persist that store. At equal timestamps, completion happens first, then readiness, signal and forced stop, and finally new admission. Therefore a completion exactly at the shutdown deadline wins here; real deployments need their own concurrency contract. The simulation uses tenth-second snapshots and stops at sixty seconds, after the last possible accepted request can finish. Fixture rejection allowance changes only the pass/fail threshold. Any killed or still-running invocation always fails the gate even at a one-hundred-percent rejection allowance.

Inspect time and worker state

Play runs sixty inspectable seconds at normal speed; Pause freezes time, and Play after completion replays from zero. Step 1 second advances to the next whole-second boundary and pauses. Restart preserves parameters and speed while returning to zero. Simulation time seeks directly and pauses. Speed provides quarter, half, normal and double pace; changing it settles elapsed time at the previous rate. A hidden tab pauses. Changing any model parameter rebuilds the plan and pauses at zero. Common baseline settings restores the shared model defaults, which differ from each page opening. Choose worker provides keyboard access to the same inspection as clicking its diagram lane. A replacement selected before its boot time has no state yet. Expand experiment changes the view; Exit full screen restores it.

Record evidence and understand the scope

Capture baseline saves the selected result and inputs; Replace baseline updates that comparison and Clear baseline removes it. Notes remain in this browser and Export notes downloads them. Scroll the diagram horizontally on phones, or focus its labeled region and use arrow keys. The worker inspector, committed sums and event trace provide text alternatives. The full-run preview intentionally exposes the eventual counts. This is a bounded teaching host, not an ADK Runner, Java process, operating-system signal, load balancer or cloud deployment. Grace and routing are configurable lesson assumptions, not provider guarantees. The fixture gate measures request accounting and the chosen rejection budget; it does not establish production availability, model quality, tenant isolation or real latency.