Introduction

Long polling in Quarkus is a practical way to deliver near real-time updates when full WebSocket infrastructure is unnecessary. The pattern keeps an HTTP request open until data is available or timeout occurs, then the client immediately reconnects. A robust implementation needs timeout handling, request cleanup, and concurrency-safe event delivery.

Long Polling Flow

Typical server flow:

1. client sends request for updates
2. server waits for event or timeout
3. server responds with payload or empty result
4. client immediately starts next request

This creates low-latency updates while staying compatible with standard HTTP tooling.

Quarkus Endpoint with Suspended Response

Using JAX-RS AsyncResponse is a straightforward approach.

1import jakarta.ws.rs.GET;
2import jakarta.ws.rs.Path;
3import jakarta.ws.rs.container.AsyncResponse;
4import jakarta.ws.rs.container.Suspended;
5import jakarta.ws.rs.core.Response;
6
7import java.util.concurrent.CopyOnWriteArrayList;
8import java.util.concurrent.TimeUnit;
9
10@Path("/updates")
11public class UpdateResource {
12
13    private static final CopyOnWriteArrayList<AsyncResponse> waiting = new CopyOnWriteArrayList<>();
14
15    @GET
16    public void poll(@Suspended AsyncResponse async) {
17        async.setTimeout(25, TimeUnit.SECONDS);
18        async.setTimeoutHandler(ar -> ar.resume(Response.noContent().build()));
19        waiting.add(async);
20    }
21
22    public static void publish(String message) {
23        for (AsyncResponse ar : waiting) {
24            ar.resume(Response.ok(message).build());
25        }
26        waiting.clear();
27    }
28}

When publish is called, all waiting clients receive data and reconnect.

Client Loop Example

A minimal JavaScript client:

1async function startLongPolling() {
2  while (true) {
3    try {
4      const res = await fetch('/updates');
5      if (res.status === 200) {
6        const msg = await res.text();
7        console.log('update:', msg);
8      }
9    } catch (err) {
10      console.error('poll error', err);
11      await new Promise((r) => setTimeout(r, 1000));
12    }
13  }
14}
15
16startLongPolling();

This loop handles reconnect behavior naturally.

Production Hardening

For production quality, add:

• request cancellation handling
• connection limits per user
• authentication on poll endpoint
• observability for wait time and timeout rate

Also ensure waiting-response collections are cleaned on resume or disconnect to prevent memory leaks.

Event Source Integration

Long-poll responses usually originate from queue events, DB state changes, or internal message buses. Decouple poll management from business event creation so endpoint code remains small and testable.

You can inject an application service that calls publish on meaningful updates only, reducing noisy responses.

Scaling Long Polling in Real Systems

As concurrent clients increase, long polling must be designed with backpressure and resource limits in mind. Track how many suspended responses are active and reject or throttle excess load gracefully.

A lightweight manager service can encapsulate queueing and cleanup:

1import jakarta.enterprise.context.ApplicationScoped;
2import jakarta.ws.rs.container.AsyncResponse;
3
4import java.util.concurrent.CopyOnWriteArrayList;
5
6@ApplicationScoped
7public class PollManager {
8    private final CopyOnWriteArrayList<AsyncResponse> waiting = new CopyOnWriteArrayList<>();
9
10    public void register(AsyncResponse response) {
11        waiting.add(response);
12    }
13
14    public void broadcast(String payload) {
15        for (AsyncResponse ar : waiting) {
16            ar.resume(payload);
17        }
18        waiting.clear();
19    }
20
21    public int waitingCount() {
22        return waiting.size();
23    }
24}

Expose waiting-count metrics and timeout-rate metrics to detect saturation before user-visible failures. For very high fan-out updates, long polling may eventually need to transition to server-sent events or WebSockets, but well-implemented long polling can still support substantial traffic.

Security and Client Identity

Long polling endpoints should validate client identity and authorization for each request. The server should not broadcast all updates to all clients unless the domain truly allows that model.

A common approach is storing waiting responses by tenant or user channel, then publishing only relevant updates. This reduces unnecessary traffic and prevents data leakage.

If authentication expires during long wait periods, return a clear status and require re-authentication before reconnect.

Common Pitfalls

A common pitfall is never timing out requests. Hanging connections can exhaust server resources.

Another issue is using non-thread-safe structures for waiting responses.

Developers also forget to remove completed responses from in-memory collections, causing leaks.

Finally, avoid sending large payloads on every poll cycle. Keep responses incremental and lightweight.

Summary

• Quarkus long polling keeps HTTP requests open until event or timeout.
• Use suspended async responses with explicit timeout handlers.
• Implement client reconnect loops with retry backoff.
• Manage waiting-response lifecycle carefully for stability.
• Add authentication, limits, and metrics before production rollout.