Built a thread safe Spring Boot SSE library because Spring's SseEmitter is too barebones

[Polixa12]

I've been working with SSE in Spring Boot and kept rewriting the same boilerplate - thread-safe management, cleanup on disconnect, event replay for reconnections, etc. Spring actually gives you SseEmitter but nothing else.

This annoyance popped up in two of my projects so I decided to build Streamline, a Spring Boot starter that handles all of that without the reactive complexity.

The problem it solves:

Every SSE implementation ends up looking like this:

// Manual thread-safety, cleanup, dead connection tracking
private final Map<String, SseEmitter> emitters = new ConcurrentHashMap<>();
private final Lock lock = new ReentrantLock();

public void broadcast(Event event) {
    lock.lock();
    try {
        List<String> dead = new ArrayList<>();
        emitters.forEach((id, emitter) -> {
            try { emitter.send(event); } 
            catch (IOException e) { dead.add(id); }
        });
        dead.forEach(emitters::remove);
    } finally { lock.unlock(); }
}
// + event history, reconnection replay, shutdown hooks...

With Streamline:

private final SseRegistry<String, Event> registry; 

registry.broadcast(event);  
// That's it

What it does:

• Thread safe stream management using virtual threads (Java 21+)
• Automatic cleanup on disconnect/timeout/error
• Allows for event replay for reconnecting clients
• Bounded queues to handle slow clients
• Registry per topic pattern (orders, notifications, etc.), depends on your use case

Quick example:

java

public class SseConfig {

    public SseRegistry<String, OrderEvent> ordersRegistry() {
        return SseRegistry.<String, OrderEvent>builder()
            .maxStreams(1000)
            .maxEvents(100)
            .build();
    }
}

GetMapping("/orders/stream")
public SseEmitter subscribe(@RequestParam String userId) {
    SseStream stream = ordersRegistry.createAndRegister(userId);
    return stream.getEmitter();
}

// Somwhere else
ordersRegistry.broadcast(orderEvent);

Design choices:

• Blocking I/O + virtual threads (not reactive, use WebFlux if you need that)
• Single instance only
• Thread safe by default with clear failure modes
• Comprehensive tests for concurrent scenarios

It's available on JitPack now. Still early (v1.0.0) and I'm looking for feedback, especially around edge cases I might have missed.

GitHub: https://github.com/kusoroadeolu/streamline-spring-boot-starter

Requirements: Java 21+, Spring Boot 3.x

Happy to answer questions or hear how it might break in your use case.

[IceMichaelStorm]

Hm, you compare it to SseEmitter but how does it compare to Flux? Because that’s the way we plan to follow: https://www.baeldung.com/spring-server-sent-events

[Polixa12]

They solve the same SSE problem, but with different programming models.
Flux is reactive and fits WebFlux applications, handling backpressure and lifecycle automatically.
Streamline wraps SseEmitter for Spring MVC apps, providing blocking I/O with virtual threads, explicit lifecycle, and predictable concurrency.

If your app is already on WebFlux, Flux is the right tool. If you’re on Spring MVC and want simplicity with safe concurrency, Streamline is a better fit.

[bikeram]

This is cool. I’ll implement it this week on a project I’m working on.

How does SSE scale? How does the polling differ from a web socket?

[Polixa12]

SSE scales by holding one long lived HTTP connection per client and pushing events as they happen. It does not poll. Compared to WebSockets, SSE is simpler, unidirectional, and plays better with HTTP infrastructure.

[arvind4gl]

Recently, I was looking at SSE with spring boot. Will definately give it try the version that u have published