# Phase 3: Agent Registry + SSE Push - Research
**Researched:** 2026-03-11
**Domain:** Agent lifecycle management, Server-Sent Events (SSE), in-memory registry
**Confidence:** HIGH
## Summary
This phase adds agent registration, heartbeat-based lifecycle management (LIVE/STALE/DEAD), and real-time command push via SSE to the Cameleer server. The technology stack is straightforward: Spring MVC's `SseEmitter` for server-push, `ConcurrentHashMap` for the in-memory agent registry, and `@Scheduled` for periodic lifecycle checks (same pattern already used by `ClickHouseFlushScheduler`).
The main architectural challenge is managing per-agent SSE connections reliably -- handling disconnections, timeouts, and cleanup without leaking threads or emitters. The command delivery model (PENDING with 60s expiry, acknowledgement) adds a second concurrent data structure to manage alongside the registry itself.
**Primary recommendation:** Use Spring MVC `SseEmitter` (already on classpath via `spring-boot-starter-web`). No new dependencies required. Follow the established core-module-plain-class / app-module-Spring-bean pattern. Agent registry service in core, SSE connection manager and controllers in app.
## User Constraints (from CONTEXT.md)
### Locked Decisions
- Heartbeat interval: 30 seconds
- STALE threshold: 90 seconds (3 missed heartbeats)
- DEAD threshold: 5 minutes after going STALE
- DEAD agents kept indefinitely (no auto-purge)
- Agent list endpoint returns all agents (LIVE, STALE, DEAD) with `?status=` filter parameter
- Generic command endpoint: `POST /api/v1/agents/{id}/commands` with `{"type": "config-update|deep-trace|replay", "payload": {...}}`
- Three targeting levels: single agent, group, all live agents
- Agent self-declares group name at registration
- Command delivery tracking: PENDING until acknowledged, 60s expiry
- Agent provides its own persistent ID at registration
- Rich registration payload: agent ID, name, group, version, list of route IDs, capabilities
- Re-registration with same ID resumes existing identity
- Heartbeat is just a ping -- no metadata update
- Registration response includes: SSE endpoint URL, current server config, server public key placeholder
- Last-Event-ID supported but does NOT replay missed events
- Pending commands NOT auto-pushed on reconnect
- SSE ping/keepalive interval: 15 seconds
### Claude's Discretion
- In-memory vs persistent storage for agent registry (in-memory is fine for v1)
- Command acknowledgement mechanism details (heartbeat piggyback vs dedicated endpoint)
- SSE implementation approach (Spring SseEmitter, WebFlux, or other)
- Thread scheduling for lifecycle state transitions
### Deferred Ideas (OUT OF SCOPE)
- Server-side agent tags/labels for more flexible grouping
- Auto-push pending commands on reconnect
- Last-Event-ID replay of missed events
- Agent capability negotiation
## Phase Requirements
| ID | Description | Research Support |
|----|-------------|-----------------|
| AGNT-01 (#13) | Agent registers via POST /api/v1/agents/register with bootstrap token, receives JWT + server public key | Registration controller + service; JWT/security enforcement deferred to Phase 4 but flow must work end-to-end |
| AGNT-02 (#14) | Server maintains agent registry with LIVE/STALE/DEAD lifecycle based on heartbeat timing | In-memory ConcurrentHashMap registry + @Scheduled lifecycle monitor |
| AGNT-03 (#15) | Agent sends heartbeat via POST /api/v1/agents/{id}/heartbeat every 30s | Heartbeat endpoint updates lastHeartbeat timestamp, transitions STALE back to LIVE |
| AGNT-04 (#16) | Server pushes config-update events to agents via SSE (Ed25519 signature deferred to Phase 4) | SseEmitter per-agent connection + command push infrastructure |
| AGNT-05 (#17) | Server pushes deep-trace commands to agents via SSE for specific correlationIds | Same SSE command push mechanism with deep-trace type |
| AGNT-06 (#18) | Server pushes replay commands to agents via SSE (signed replay tokens deferred to Phase 4) | Same SSE command push mechanism with replay type |
| AGNT-07 (#19) | SSE connection includes ping keepalive and supports Last-Event-ID reconnection | 15s ping via @Scheduled, Last-Event-ID header read on connect |
## Standard Stack
### Core
| Library | Version | Purpose | Why Standard |
|---------|---------|---------|--------------|
| Spring MVC SseEmitter | 6.2.x (via Boot 3.4.3) | Server-Sent Events | Already on classpath, servlet-based (matches existing stack), no WebFlux needed |
| ConcurrentHashMap | JDK 17 | Agent registry storage | Thread-safe, O(1) lookup by agent ID, no external dependency |
| Spring @Scheduled | 6.2.x (via Boot 3.4.3) | Lifecycle monitor + SSE keepalive | Already enabled in application, proven pattern in ClickHouseFlushScheduler |
### Supporting
| Library | Version | Purpose | When to Use |
|---------|---------|---------|-------------|
| Jackson ObjectMapper | 2.17.3 (managed) | Command serialization/deserialization | Already configured with JavaTimeModule, used throughout codebase |
### Alternatives Considered
| Instead of | Could Use | Tradeoff |
|------------|-----------|----------|
| SseEmitter (MVC) | WebFlux Flux | Would require adding spring-boot-starter-webflux and mixing reactive/servlet stacks -- unnecessary complexity for this use case |
| ConcurrentHashMap | Redis/ClickHouse persistence | Over-engineering for v1; in-memory is sufficient since agent state is ephemeral and rebuilt on reconnect |
| @Scheduled | ScheduledExecutorService | @Scheduled already works, already enabled; raw executor only needed for complex scheduling |
**Installation:**
No new dependencies required. Everything is already on the classpath.
## Architecture Patterns
### Recommended Project Structure
```
cameleer-server-core/src/main/java/com/cameleer/server/core/
├── agent/
│ ├── AgentInfo.java # Record: id, name, group, version, routeIds, capabilities, state, timestamps
│ ├── AgentState.java # Enum: LIVE, STALE, DEAD
│ ├── AgentRegistryService.java # Plain class: register, heartbeat, findById, findAll, lifecycle transitions
│ ├── AgentCommand.java # Record: id, type, payload, targetAgentId, createdAt, status
│ └── CommandStatus.java # Enum: PENDING, DELIVERED, ACKNOWLEDGED, EXPIRED
cameleer-server-app/src/main/java/com/cameleer/server/app/
├── config/
│ ├── AgentRegistryConfig.java # @ConfigurationProperties(prefix = "agent-registry")
│ └── AgentRegistryBeanConfig.java # @Configuration: wires AgentRegistryService as bean
├── controller/
│ ├── AgentRegistrationController.java # POST /register, POST /{id}/heartbeat, GET /agents
│ ├── AgentCommandController.java # POST /{id}/commands, POST /groups/{group}/commands, POST /commands
│ └── AgentSseController.java # GET /{id}/events (SSE stream)
├── agent/
│ ├── SseConnectionManager.java # @Component: ConcurrentHashMap, ping scheduler
│ └── AgentLifecycleMonitor.java # @Component: @Scheduled lifecycle check (like ClickHouseFlushScheduler)
```
### Pattern 1: Core Module Plain Class + App Module Bean Config
**What:** Domain logic in core module as plain Java classes; Spring wiring in app module via @Configuration
**When to use:** Always -- this is the established codebase pattern
**Example:**
```java
// Core module: plain class, no Spring annotations
public class AgentRegistryService {
private final ConcurrentHashMap agents = new ConcurrentHashMap<>();
public AgentInfo register(String id, String name, String group, String version,
List routeIds, Map capabilities) {
AgentInfo existing = agents.get(id);
if (existing != null) {
// Re-registration: update metadata, transition back to LIVE
AgentInfo updated = existing.withState(AgentState.LIVE)
.withLastHeartbeat(Instant.now());
agents.put(id, updated);
return updated;
}
AgentInfo agent = new AgentInfo(id, name, group, version, routeIds,
capabilities, AgentState.LIVE, Instant.now(), Instant.now());
agents.put(id, agent);
return agent;
}
public boolean heartbeat(String id) {
return agents.computeIfPresent(id, (k, v) ->
v.withState(AgentState.LIVE).withLastHeartbeat(Instant.now())) != null;
}
}
// App module: bean config
@Configuration
public class AgentRegistryBeanConfig {
@Bean
public AgentRegistryService agentRegistryService() {
return new AgentRegistryService();
}
}
```
### Pattern 2: SseEmitter Per-Agent Connection
**What:** Each agent has one SseEmitter stored in ConcurrentHashMap, managed by a dedicated component
**When to use:** For all SSE connections to agents
**Example:**
```java
@Component
public class SseConnectionManager {
private final ConcurrentHashMap emitters = new ConcurrentHashMap<>();
public SseEmitter connect(String agentId) {
// Use Long.MAX_VALUE timeout -- we manage keepalive ourselves
SseEmitter emitter = new SseEmitter(Long.MAX_VALUE);
emitter.onCompletion(() -> emitters.remove(agentId));
emitter.onTimeout(() -> emitters.remove(agentId));
emitter.onError(e -> emitters.remove(agentId));
// Replace any existing emitter (agent reconnect)
SseEmitter old = emitters.put(agentId, emitter);
if (old != null) {
old.complete(); // Close stale connection
}
return emitter;
}
public boolean sendEvent(String agentId, String eventId, String eventType, Object data) {
SseEmitter emitter = emitters.get(agentId);
if (emitter == null) return false;
try {
emitter.send(SseEmitter.event()
.id(eventId)
.name(eventType)
.data(data, MediaType.APPLICATION_JSON));
return true;
} catch (IOException e) {
emitters.remove(agentId);
return false;
}
}
public void sendPingToAll() {
emitters.forEach((id, emitter) -> {
try {
emitter.send(SseEmitter.event().comment("ping"));
} catch (IOException e) {
emitters.remove(id);
}
});
}
}
```
### Pattern 3: Lifecycle Monitor via @Scheduled
**What:** Periodic task checks all agents' lastHeartbeat timestamps and transitions states
**When to use:** For LIVE->STALE and STALE->DEAD transitions
**Example:**
```java
@Component
public class AgentLifecycleMonitor {
private final AgentRegistryService registry;
private final AgentRegistryConfig config;
@Scheduled(fixedDelayString = "${agent-registry.lifecycle-check-interval-ms:10000}")
public void checkLifecycle() {
Instant now = Instant.now();
for (AgentInfo agent : registry.findAll()) {
Duration sinceHeartbeat = Duration.between(agent.lastHeartbeat(), now);
if (agent.state() == AgentState.LIVE
&& sinceHeartbeat.toMillis() > config.getStaleThresholdMs()) {
registry.transitionState(agent.id(), AgentState.STALE);
} else if (agent.state() == AgentState.STALE
&& sinceHeartbeat.toMillis() > config.getStaleThresholdMs() + config.getDeadThresholdMs()) {
registry.transitionState(agent.id(), AgentState.DEAD);
}
}
}
}
```
### Anti-Patterns to Avoid
- **Mixing WebFlux and MVC:** Do not add spring-boot-starter-webflux. The project uses servlet-based MVC. Adding WebFlux creates classpath conflicts and ambiguity.
- **Sharing SseEmitter across threads without protection:** Always use ConcurrentHashMap and handle IOException on every send. A failed send means the client disconnected.
- **Storing SseEmitter in the core module:** SseEmitter is a Spring MVC class. Keep it in the app module only. The core module should define interfaces for "push event to agent" that the app module implements.
- **Not setting SseEmitter timeout:** Default timeout is server-dependent (often 30s). Use `Long.MAX_VALUE` and manage keepalive yourself.
## Don't Hand-Roll
| Problem | Don't Build | Use Instead | Why |
|---------|-------------|-------------|-----|
| SSE protocol | Custom HTTP streaming | Spring SseEmitter | Handles text/event-stream format, event IDs, retry fields automatically |
| Thread-safe map | Synchronized HashMap | ConcurrentHashMap | Lock-free reads, segmented writes, battle-tested |
| Periodic scheduling | Manual Thread/Timer | @Scheduled + @EnableScheduling | Already configured, integrates with Spring lifecycle |
| JSON serialization | Manual string building | ObjectMapper (already configured) | Handles Instant, unknown fields, all edge cases |
| Async request timeout | Manual thread management | spring.mvc.async.request-timeout config | Spring handles Tomcat async timeout correctly |
**Key insight:** SSE in Spring MVC is a well-supported, first-class feature. The SseEmitter API handles the wire protocol; your job is managing the lifecycle of emitters (create, store, cleanup, send).
## Common Pitfalls
### Pitfall 1: SseEmitter Default Timeout Kills Long-Lived Connections
**What goes wrong:** Emitter times out after 30s (Tomcat default), client gets disconnected
**Why it happens:** Not setting explicit timeout on SseEmitter constructor
**How to avoid:** Always use `new SseEmitter(Long.MAX_VALUE)`. Also set `spring.mvc.async.request-timeout=-1` in application.yml to disable the MVC-level async timeout
**Warning signs:** Clients disconnecting every 30 seconds, reconnection storms
### Pitfall 2: IOException on Send Not Handled
**What goes wrong:** Client disconnects but server keeps trying to send, gets IOException, does not clean up
**Why it happens:** Not wrapping every `emitter.send()` in try-catch
**How to avoid:** Every send must catch IOException, remove the emitter from the map, and log at debug level (not error -- disconnects are normal)
**Warning signs:** Growing emitter map, increasing IOExceptions in logs
### Pitfall 3: Race Condition on Agent Reconnect
**What goes wrong:** Agent disconnects and reconnects rapidly; old emitter and new emitter both exist briefly
**Why it happens:** `onCompletion` callback of old emitter fires after new emitter is stored, removing the new one
**How to avoid:** Use `ConcurrentHashMap.put()` which returns the old value. Only remove in callbacks if the emitter in the map is still the same instance (reference equality check)
**Warning signs:** Agent SSE stream stops working after reconnect
### Pitfall 4: Tomcat Thread Exhaustion with SSE
**What goes wrong:** Each SSE connection holds a Tomcat thread (with default sync mode)
**Why it happens:** MVC SseEmitter uses Servlet 3.1 async support but the async processing still occupies a thread from the pool during the initial request
**How to avoid:** Spring Boot's default Tomcat thread pool (200 threads) is sufficient for dozens to low hundreds of agents. If scaling beyond that, configure `server.tomcat.threads.max`. For thousands of agents, consider WebFlux (but that is a v2 concern)
**Warning signs:** Thread pool exhaustion, connection refused errors
### Pitfall 5: Command Expiry Not Cleaned Up
**What goes wrong:** Expired PENDING commands accumulate in memory
**Why it happens:** No scheduled task to clean them up
**How to avoid:** The lifecycle monitor (or a separate @Scheduled task) should also sweep expired commands every check cycle
**Warning signs:** Memory growth over time, stale commands in API responses
### Pitfall 6: SSE Endpoint Blocked by ProtocolVersionInterceptor
**What goes wrong:** SSE GET request rejected because it lacks `X-Cameleer-Protocol-Version` header
**Why it happens:** WebConfig already registers the interceptor for `/api/v1/agents/**` which includes the SSE endpoint
**How to avoid:** Either add the protocol header requirement to agents (recommended -- agents already send it for POST requests) or exclude the SSE endpoint path from the interceptor
**Warning signs:** 400 errors on SSE connect attempts
## Code Examples
### Registration Controller
```java
@RestController
@RequestMapping("/api/v1/agents")
@Tag(name = "Agent Management", description = "Agent registration and lifecycle endpoints")
public class AgentRegistrationController {
private final AgentRegistryService registryService;
private final ObjectMapper objectMapper;
@PostMapping("/register")
@Operation(summary = "Register an agent")
public ResponseEntity register(@RequestBody String body) throws JsonProcessingException {
// Parse registration payload
JsonNode node = objectMapper.readTree(body);
String agentId = node.get("agentId").asText();
String name = node.get("name").asText();
String group = node.has("group") ? node.get("group").asText() : "default";
// ... extract other fields
AgentInfo agent = registryService.register(agentId, name, group, version, routeIds, capabilities);
// Build registration response
Map response = new LinkedHashMap<>();
response.put("agentId", agent.id());
response.put("sseEndpoint", "/api/v1/agents/" + agentId + "/events");
response.put("heartbeatIntervalMs", 30000);
response.put("serverPublicKey", null); // Phase 4
// JWT token placeholder -- Phase 4 will add real JWT
response.put("token", "placeholder-" + agentId);
return ResponseEntity.ok(objectMapper.writeValueAsString(response));
}
@PostMapping("/{id}/heartbeat")
@Operation(summary = "Agent heartbeat ping")
public ResponseEntity heartbeat(@PathVariable String id) {
boolean found = registryService.heartbeat(id);
if (!found) {
return ResponseEntity.notFound().build();
}
return ResponseEntity.ok().build();
}
@GetMapping
@Operation(summary = "List all agents")
public ResponseEntity listAgents(
@RequestParam(required = false) String status) throws JsonProcessingException {
List agents;
if (status != null) {
AgentState stateFilter = AgentState.valueOf(status.toUpperCase());
agents = registryService.findByState(stateFilter);
} else {
agents = registryService.findAll();
}
return ResponseEntity.ok(objectMapper.writeValueAsString(agents));
}
}
```
### SSE Controller
```java
@RestController
@RequestMapping("/api/v1/agents")
@Tag(name = "Agent SSE", description = "Server-Sent Events for agent communication")
public class AgentSseController {
private final SseConnectionManager connectionManager;
private final AgentRegistryService registryService;
@GetMapping(value = "/{id}/events", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
@Operation(summary = "SSE event stream for an agent")
public SseEmitter subscribe(
@PathVariable String id,
@RequestHeader(value = "Last-Event-ID", required = false) String lastEventId) {
AgentInfo agent = registryService.findById(id);
if (agent == null) {
throw new ResponseStatusException(HttpStatus.NOT_FOUND, "Agent not registered");
}
// Last-Event-ID acknowledged but no replay (per decision)
if (lastEventId != null) {
log.debug("Agent {} reconnected with Last-Event-ID: {} (no replay)", id, lastEventId);
}
return connectionManager.connect(id);
}
}
```
### Command Acknowledgement Endpoint (Recommended: Dedicated Endpoint)
```java
@PostMapping("/{id}/commands/{commandId}/ack")
@Operation(summary = "Acknowledge command receipt")
public ResponseEntity acknowledgeCommand(
@PathVariable String id,
@PathVariable String commandId) {
boolean acknowledged = registryService.acknowledgeCommand(id, commandId);
if (!acknowledged) {
return ResponseEntity.notFound().build();
}
return ResponseEntity.ok().build();
}
```
### Application Configuration Addition
```yaml
# application.yml additions
agent-registry:
heartbeat-interval-ms: 30000
stale-threshold-ms: 90000
dead-threshold-ms: 300000 # 5 minutes after last heartbeat (not after going stale)
ping-interval-ms: 15000
command-expiry-ms: 60000
lifecycle-check-interval-ms: 10000
spring:
mvc:
async:
request-timeout: -1 # Disable async timeout for SSE
```
## State of the Art
| Old Approach | Current Approach | When Changed | Impact |
|--------------|------------------|--------------|--------|
| Polling for agent status | SSE push for commands | Always SSE for server-push | Immediate delivery, lower latency |
| WebFlux for SSE | MVC SseEmitter | Spring 4.2+ | MVC SseEmitter is sufficient for moderate scale; no need for reactive stack |
| Custom HTTP streaming | SseEmitter.event() builder | Spring 4.2+ | Wire protocol handled automatically |
**Deprecated/outdated:**
- `ResponseBodyEmitter` directly for SSE: Use `SseEmitter` which extends it with SSE-specific features
- `DeferredResult` for server push: Only for single-value responses, not streams
## Open Questions
1. **Command acknowledgement: dedicated endpoint vs heartbeat piggyback**
- What we know: Dedicated endpoint is simpler, more explicit, and decoupled from heartbeat
- What's unclear: Whether agent-side implementation prefers one approach
- Recommendation: Use dedicated `POST /{id}/commands/{commandId}/ack` endpoint. Cleaner separation of concerns, easier to test, and does not complicate the heartbeat path
2. **Dead threshold calculation: from last heartbeat or from STALE transition?**
- What we know: CONTEXT.md says "5 minutes after going STALE"
- What's unclear: Whether to track staleTransitionTime separately or compute from lastHeartbeat
- Recommendation: Track `staleTransitionTime` in AgentInfo. Dead threshold = 5 minutes after `staleTransitionTime`. This matches the stated requirement precisely
3. **Async timeout vs SseEmitter timeout**
- What we know: Both `spring.mvc.async.request-timeout` and `new SseEmitter(timeout)` affect SSE lifetime
- What's unclear: Interaction between the two
- Recommendation: Set `SseEmitter(Long.MAX_VALUE)` AND `spring.mvc.async.request-timeout=-1`. Belt and suspenders -- both disabled ensures no premature timeout
## Validation Architecture
### Test Framework
| Property | Value |
|----------|-------|
| Framework | JUnit 5 + Spring Boot Test (via spring-boot-starter-test) |
| Config file | pom.xml (Surefire + Failsafe configured) |
| Quick run command | `mvn test -pl cameleer-server-core -Dtest=AgentRegistryServiceTest` |
| Full suite command | `mvn clean verify` |
### Phase Requirements to Test Map
| Req ID | Behavior | Test Type | Automated Command | File Exists? |
|--------|----------|-----------|-------------------|-------------|
| AGNT-01 | Agent registers and gets response | integration | `mvn test -pl cameleer-server-app -Dtest=AgentRegistrationControllerIT#registerAgent*` | No - Wave 0 |
| AGNT-02 | Lifecycle transitions LIVE/STALE/DEAD | unit | `mvn test -pl cameleer-server-core -Dtest=AgentRegistryServiceTest#lifecycle*` | No - Wave 0 |
| AGNT-03 | Heartbeat updates timestamp, returns 200/404 | integration | `mvn test -pl cameleer-server-app -Dtest=AgentRegistrationControllerIT#heartbeat*` | No - Wave 0 |
| AGNT-04 | Config-update pushed via SSE | integration | `mvn test -pl cameleer-server-app -Dtest=AgentSseControllerIT#configUpdate*` | No - Wave 0 |
| AGNT-05 | Deep-trace command pushed via SSE | integration | `mvn test -pl cameleer-server-app -Dtest=AgentSseControllerIT#deepTrace*` | No - Wave 0 |
| AGNT-06 | Replay command pushed via SSE | integration | `mvn test -pl cameleer-server-app -Dtest=AgentSseControllerIT#replay*` | No - Wave 0 |
| AGNT-07 | SSE ping keepalive + Last-Event-ID | integration | `mvn test -pl cameleer-server-app -Dtest=AgentSseControllerIT#pingKeepalive*` | No - Wave 0 |
### Sampling Rate
- **Per task commit:** `mvn test -pl cameleer-server-core,cameleer-server-app -Dtest="Agent*"` (agent-related tests only)
- **Per wave merge:** `mvn clean verify`
- **Phase gate:** Full suite green before /gsd:verify-work
### Wave 0 Gaps
- [ ] `cameleer-server-core/.../agent/AgentRegistryServiceTest.java` -- covers AGNT-02, AGNT-03 (unit tests for registry logic)
- [ ] `cameleer-server-app/.../controller/AgentRegistrationControllerIT.java` -- covers AGNT-01, AGNT-03
- [ ] `cameleer-server-app/.../controller/AgentSseControllerIT.java` -- covers AGNT-04, AGNT-05, AGNT-06, AGNT-07
- [ ] `cameleer-server-app/.../controller/AgentCommandControllerIT.java` -- covers command targeting (single, group, all)
- [ ] No new framework install needed -- JUnit 5 + Spring Boot Test + Awaitility already in place
### SSE Test Strategy
Testing SSE with `TestRestTemplate` requires special handling. Use Spring's `WebClient` from WebFlux test support or raw `HttpURLConnection` to read the SSE stream. Alternatively, test at the service layer (SseConnectionManager) with direct emitter interaction. The integration test should:
1. Register agent via POST
2. Open SSE connection (separate thread)
3. Send command via POST
4. Assert SSE stream received the event
5. Verify with Awaitility for async assertions
## Sources
### Primary (HIGH confidence)
- [SseEmitter Javadoc (Spring Framework 7.0.5)](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/servlet/mvc/method/annotation/SseEmitter.html) - Full API reference
- [Asynchronous Requests :: Spring Framework](https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-ann-async.html) - Official async request handling docs
- [Task Execution and Scheduling :: Spring Boot](https://docs.spring.io/spring-boot/reference/features/task-execution-and-scheduling.html) - Official scheduling docs
- Existing codebase: ClickHouseFlushScheduler, IngestionService, IngestionBeanConfig, WebConfig patterns
### Secondary (MEDIUM confidence)
- [Spring Boot SSE SseEmitter tutorial](https://nitinkc.github.io/microservices/sse-springboot/) - Complete guide with patterns
- [SseEmitter timeout issue #4021](https://github.com/spring-projects/spring-boot/issues/4021) - Timeout handling gotchas
- [SseEmitter response closed #19652](https://github.com/spring-projects/spring-framework/issues/19652) - Thread safety discussion
### Tertiary (LOW confidence)
- Various Medium articles on SSE patterns - used for cross-referencing community patterns only
## Metadata
**Confidence breakdown:**
- Standard stack: HIGH - SseEmitter is built into Spring MVC, already on classpath, well-documented API
- Architecture: HIGH - follows established codebase patterns (core plain class, app bean config, @Scheduled)
- Pitfalls: HIGH - well-known issues documented in Spring GitHub issues and multiple sources
- SSE test strategy: MEDIUM - SSE testing with TestRestTemplate is non-trivial, may need adaptation
**Research date:** 2026-03-11
**Valid until:** 2026-04-11 (stable stack, no fast-moving dependencies)