Live Activity

On Quarkus, scheduled capture covers blocking @Scheduled methods. A method returning a Uni or CompletionStage completes later, and its run carries no execution id.

A cache miss has WARN severity; other cache rows are OK. The detail shows key a1b2c3….

Across the top: requests per minute, error rate, p50/p95 latency, SQL rate, the slowest recent endpoint, active exception count, health status, heap usage, and scheduled-task failure count. On Spring servlet and WebFlux only, outbound REST-call error rate and p95 latency, plus the cache hit ratio. All are computed from the same buffers, and sub-millisecond SQL is shown as <1 ms.

The p50/p95 latency and the slowest request are computed once, in the shared engine, over every retained request with a duration, so Spring MVC, Spring WebFlux, and Quarkus report the same figures for the same traffic; the latency card states how many requests they cover. The slowest request is labelled with its resolved route, such as GET /api/orders/{id}, and a tie goes to the newest request.

Several cards are launchpads: outbound-errors opens REST Client, slowest-endpoint opens that route's row in the HTTP Exchanges route rankings with its exchanges listed, and the active-exceptions, health, heap-usage, cache-hit-ratio, and scheduled-failures cards jump to Exceptions, Health, Heap Dump, Cache, and Scheduled Tasks.

MARKER rows come from the runtime journal: a logger level, a configuration override, a cache clear, a migration, Clear recording, or a heap dump changed from a BootUI panel, an availability change, a configuration refresh, or shutdown.

APP_EVENT rows list the application events a request published and each listener's run. On Spring, they come through BootUI's event multicaster, including transactional listeners' deferral, effective execution phase, and skips. A listener running through fallbackExecution without an active transaction is IMMEDIATE, regardless of its annotation's phase. A deferred callback retains its transaction phase, including a reactive transaction carried in the event's source. When the application defines its own multicaster, as Spring Modulith's event publication registry does, BootUI keeps it and records no application event. On Quarkus, listener runs are recorded through an interceptor bound at build time to the application's @Observes and @ObservesAsync methods. Framework events are left out, and an event's fields are never recorded. Change impact accepts an event type, such as OrderPlaced, and lists the routes that published or consumed it.

ORM rows give each Hibernate session's statements, flushes, the auto-flushes that wrote before a query, and the most entities its persistence context held, under the request that opened it.

WEBSOCKET rows are inbound WebSocket messages, each an execution owning what its handler did.

ASYNC rows need the BootUI agent. They are the tasks a request handed to a JDK executor, nested under it: the task's class, the hook that propagated it, its queue time, and its outcome. A task is badged:

• after response when it worked once the response started: its body was still running, or, after a body that ended before, a dependent stage or done() callback ran SQL, a REST call, or a message, failed, or ran 50 ms, after it. A task whose handler waited for its result is not badged merely because its run closed just after the response.
• running while it still runs.
• past deadline when it ended more than bootui.agent.executors.max-handoff after it started.

The request's journal profile lists them under Handoffs, each with its thread, duration, queue time, what it did (SQL statements, REST calls, and messages), its outcome, and its allocated bytes. A task that started more than max-handoff after the request ended is only counted, and neither it nor its work is drawn on the timeline.

One shared engine assembler builds the profile on every adapter, so identical evidence gives an identical profile. A servlet request runs on one worker thread that serves one request at a time, so work on that thread is its own.

The Propagated tier applies when the task started within bootui.agent.executors.max-handoff of the request's end and the work within max-handoff of the task's start. It is unavailable, with the reason, unless the agent's executors sensor propagates for the application.

On WebFlux and Quarkus a request is profileable when it carries a request id or a trace id, so tracing is not required. For SQL, the time-window fallback applies only when no statement matched a request id, a trace id, or the serving thread. On Spring MVC, exceptions still match the request's method, path, and window; a trace id or the serving thread then settles which request threw them. Security events match by time window and principal, but are pinned to the serving thread when captured there, and an event proven to have fired on another thread is excluded.

A signal attaches to at most one request. A trace id shared by two captured requests (a reused inbound traceparent, or an application calling itself) attaches nothing to either, and a signal two requests could equally claim, such as a statement inside the overlapping windows of two identical concurrent requests, stays out of both. The notes count every such signal. When a section mixes tiers, each entry names its tier.

REST client calls are shown as the REST Client panel shows them, with values masked by the same policy. Cache accesses carry only the short key hash. Both attach by request id, then a unique trace id, and on MVC by serving thread, never by time window. Quarkus has no cache-access capture seam, so its cache section says so.

N+1 groups and timing count every correlated statement and call; at most 200 statement groups are listed. When Code Paths is disabled, unavailable, or has no retained tree for the request, the drawer says why.

Each correlated exception carries its exceptionGroupId, the id of its group in the Exceptions panel. Agents use get_request_profile or bootui request-profile <id>, which return a selection with journal and buffers evidence when retained, preferring the journal in source ("journal", "buffers", or "none"). A request's profile is unavailable while the HTTP Exchanges panel is disabled, because it opens with that request's exchange.

Scheduled runs, consumed messages, and inbound WebSocket handlers can also be opened by execution id when their completed anchor is retained and its source panel is enabled. WebSocket profiles use the captured destination template, or the endpoint when none is recorded, and include only retained, enabled-panel work correlated to that execution. Outbound messages and session open/close events never open an execution profile. Each retained event is selected once, even when an executor handoff shares its parent's execution id; individual task counts are then qualified as unavailable rather than claiming nothing was recorded. These executions have no HTTP status, route comparison, or measured CPU, allocation, and GC pauses. Scheduled runs are not child events in an HTTP request's buffer-backed profile or exports. See Investigate one request.

The REST Client panel keeps its own "chatty" badge for now.

The omitted list covers values BootUI masked, truncated or unavailable sections, exception messages withheld by bootui.expose-values=METADATA_ONLY, and details that could no longer be loaded. Preparing the preview reads each referenced exception group through the Exceptions panel's existing read endpoint, at most five groups.

Both documents come from one shared helper that works only on DTOs the browser already holds, so the export never contains anything the panels do not show, and identical evidence produces identical text on every stack. Captured messages, paths, and SQL are escaped or fenced, so Markdown inside them cannot break the document's structure.

For Kafka on Spring, whose client reports a send on its own I/O thread, BootUI snapshots the sender's context when KafkaTemplate sends the record. On Quarkus, the execution id is attached to the Vert.x context SmallRye Reactive Messaging processes the message on, so it follows the listener to a worker thread, and a send's context is snapshotted when the message enters its channel.

On Spring, BootUI wraps every application-owned KafkaTemplate with a ProducerListener and every @KafkaListener container factory with a RecordInterceptor, composing with whatever the application configured. On Quarkus, it hooks SmallRye Reactive Messaging's Kafka interceptors.

Each entry records topic, partition, offset (consumed only), a hash of the key, direction, and success or failure, plus consumer group id, listener identifier, and processing duration for consumed records. A producer send's duration is not exposed by either framework's callback. The listener identifier is the listener container factory bean name on Spring (the per-@KafkaListener id is not exposed there) and the channel name on Quarkus.

Capture is on by default when the Kafka integration is present and the panel is enabled. Tune it with bootui.kafka.enabled, bootui.kafka.capture-key, bootui.kafka.max-entries, and bootui.kafka.max-key-length.

Requires spring-jms and jakarta.jms on the classpath. Every JmsTemplate bean is wrapped by a CGLIB proxy that intercepts send/convertAndSend, and every AbstractJmsListenerContainerFactory bean is proxied so each container's listener is wrapped by a matching plain or session-aware adapter. Both compose with the application's converters, callbacks, and error handlers. Direct JMSContext, MessageProducer, or MessageConsumer usage is outside this seam.

Each entry records a sanitized destination name (only explicit names and standard Queue/Topic accessors are trusted), direction, success or failure, and duration. When a MessageCreator or MessagePostProcessor exposes the JMS message ID, only its one-way hash is retained. Payloads, arbitrary headers and properties, the raw message ID, and exception messages are never captured.

JMS has its own recorder, buffer, and mapper, so it cannot evict Kafka history and either can be disabled independently. Tune it with bootui.jms.enabled, bootui.jms.capture-message-id, bootui.jms.max-entries, and bootui.jms.max-message-id-length. No Quarkus JMS equivalent is claimed.

The table (bootui.activity.persistence.table-name, default bootui_activity) is created on first use. Several instances can share one table: each tags its rows with an instanceId (defaulting to HOSTNAME) and never reads or prunes another instance's rows. Reads merge the in-memory buffer with the durable store, and a failed flush returns its entries to the buffer.

Changing a query or feed source discards its older pages, and a late page from a previous query cannot add rows or replace the cursor. Switching between durable and in-memory storage also resets history. A disabled source panel hides its older rows; a history page scans past them within a bounded read budget and keeps a continuation cursor, so a page can be empty while Load older is still available.

Each journal batch is rendered as the journal feed renders it and stored once, so a burst is not lost between reads of the panel buffers. Failed and slow entries are remembered longer, in one window per kind, bootui.activity.persistence.buffer-max-entries wide, recognized by the rule and threshold of the failure-preserving buffer. This replaces the 1.x buffer-polling path; applications that relied on the omitted details must read the bounded live panel evidence.

With persistence off, no subscriber, flush scheduler, or database connection is created.

The switch starts the journal subscriber against the new store, then hot-switches without losing events dispatched in between. Concurrent requests start one capture; repeats are no-ops. If capture cannot start after schema verification, HTTP 500 says the table may already exist but in-memory storage remains active; BootUI never deletes a host table to undo it. Journal shutdown during the switch also rejects it and closes the unused capture and store.

The action rejects an unavailable, disabled, or closed journal with HTTP 409 before creating a table, and never silently enables capture. Opening the database disclosure checks journal status on demand; the switch stays disabled with an explanation while capture is disabled, unavailable, or unverifiable, since datasource presence alone does not prove events can be saved.

The switch and Clear recording report success only after a valid JSON acknowledgement. Otherwise they report an unknown outcome and re-read the feed or journal status, keeping prior local evidence if that fails. The browser never repeats either action automatically.

A log event keeps its unformatted template, never its arguments. SQL statements, REST client calls, and cache accesses keep up to four frames of your own code that issued them, skipping framework classes and generated proxies. A message consumed with a traceparent header keeps the trace that sent it. SQL events from named JDBC pools retain the pool name even when connection recording is disabled.

A task a request hands to a framework-managed executor (an @Async method on Spring Boot's auto-configured executor or scheduler, or a Quarkus ManagedExecutor task) runs as an execution of that request. On Spring, the application's own ThreadPoolTaskExecutor, ThreadPoolTaskScheduler, and SimpleAsyncTaskExecutor beans get the same, including one wrapped by another executor bean, as JHipster's AsyncConfigurer wraps its pool. An executor with its own task decorator keeps it, with BootUI's composed inside. An executor that is not a bean keeps no request link. A periodic or cron task belongs to the request that scheduled it on its first run only. Without the BootUI agent, raw executors and CompletableFuture are not followed; with it attached, they are propagated too (Java Agent).

Pausing a panel's recording, or BootUI releasing its buffers while the console is idle (bootui.free-on-idle), stops only what that panel keeps: the journal keeps recording SQL statements, connections, transactions, REST client calls, AI calls, and security events.

With the BootUI agent attached, the status also reports, as Agent evidence, the memory its evidence kept outside the journal uses against bootui.runtime-journal.agent-evidence-max-bytes. Clear recording, and Free BootUI memory, drop that evidence too: Code Paths' request and route trees, Code Inventory's first requests and routes, and Side Effects rows. The status counts Side Effects as sideEffectRows and sideEffectsWaiting.

When the application restarts in the same JVM (a DevTools restart or Quarkus live reload), BootUI keeps a summary of the run that ended, at most 256 KB each, for the 5 most recent runs. Each run carries its application (name and whether it is a test), so when several applications share the JVM, as Spring test contexts do, a run is compared only with its own application's runs, and each application keeps its last run. Previous runs lists them with requests, failures, and events, or says why none can be kept when BootUI itself is reloaded with the application.

A summary keeps per-route, per-statement-fingerprint, and per-exception-group counts and histograms, and the edges its requests, jobs, and listeners observed (such as a route reading a table or calling a host). It also keeps what the run recorded at start: time to ready and slowest bean instantiations (Spring), active profiles, data source URL shapes, cache, and whether tracing was on, which decide whether two runs can be compared. To keep the last run across a full JVM restart, set bootui.runtime-journal.baseline-file, for example target/bootui-baseline.bin: the summary is written there when the run ends and read back at the next start.

The live policy applies in the panel, get_live_activity, bootui activity, request journal profiles, and the KPI strip. Under MASKED, double-quoted runs and an unterminated dollar quote of a truncated statement are replaced too. FULL, or MASKED with bootui.mask-secrets=false, shows SQL and log text as recorded.

Each stored row is masked again under the live mode when it is read: never shown less masked than MASKED, and under METADATA_ONLY with its free text (log messages, exception messages, principals, email subjects and recipients) dropped while its structural label, such as GET /orders → 200 or a SQL shape, stays. A stored row is also read only while the panel that owns it is enabled: disabling SQL Trace, Logs, or any other source panel hides its rows already written to durable history, as it does for live rows. A search of durable history matches only the text each row shows, so it never finds a row by text masked or withheld on read.

A SQL statement that mixes a quote with a backslash or a #, which MySQL and MariaDB may read as an escaped quote or a comment, is cut at its first quote rather than guessed at.