0

I have the event stream code block below:

    @RequestMapping(value = "/stream/{columnId}/data", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    @ResponseBody
    public Flux<Activity> streamingData(@PathVariable String columnId, HttpSession httpSession) {
        try {
            ColumnObject columnObject = streamHelper.findColumnObjectInListById(columnId);
            return streamHelper.getStreamData(httpSession.getId(), columnObject);
        } catch (Exception e) {
            ...
        }
    }

After creating 6 columns through the endpoint, spring server will put all subsequent requests in the pending state.

( get, post methods for example)

@RequestMapping(value = "/session/metrics", method = RequestMethod.GET)
    public ResponseEntity<?> keepSessionAliveMetrics(HttpSession httpSession) {
        return new ResponseEntity<Void>(HttpStatus.OK); // STATE ONLY PENDING 
    }

enter image description here

Bear
  • 662
  • 1
  • 5
  • 20
Erdem Aydemir
  • 389
  • 1
  • 6
  • 26
  • This is a hard browser limit. See https://stackoverflow.com/questions/985431/max-parallel-http-connections-in-a-browser. Spring isn't doing anything here, it is your browser. – M. Deinum Jul 16 '18 at 13:41
  • Thanks for comment. I understand. How can you suggest a solution, my friend @M.Deinum – Erdem Aydemir Jul 16 '18 at 13:47
  • Fix your software/find a different way. The browser simply cannot handle more requests (and it even differs per browser). – M. Deinum Jul 16 '18 at 13:49

3 Answers3

0

As pointed out by Marten Deinum, this is a typical hard limit: browsers tend to limit the number of concurrent connections to a given domain.

If your application requires a lot of multiplexing, maybe using WebSockets is a better option as many message channels are established on a single TCP connection.

Brian Clozel
  • 56,583
  • 15
  • 167
  • 176
  • I think you're right. I already used WebSocket before event stream. But once you start using the Reactor API, the event stream makes more sense. Event stream can be managed more easily than websocket. You can see the example of the above controller code. As a result I could not imagine that such a problem would arise. – Erdem Aydemir Jul 17 '18 at 07:06
  • Spring WebFlux is considering alternate transports as well, see https://jira.spring.io/browse/SPR-16751 – Brian Clozel Jul 17 '18 at 08:09
0

To bypass this limitation of the browsers, you can use Server-Sent Events over HTTP/2: HTTP/2 provides a multiplexing feature that enables to circumvent this HTTP/1 issue. There is an excellent article about that: https://www.smashingmagazine.com/2018/02/sse-websockets-data-flow-http2/

SpringBoot has an HTTP/2 support but may be not Spring WebFlux (with Netty, at least, at the time of writing): https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-http2

ctranxuan
  • 785
  • 5
  • 9
0

Using SSE over HTTP/2 is certainly the best way to overcome the limitations your are experiencing. You can find more detailed information here: https://www.infoq.com/articles/websocket-and-http2-coexist

Allan D.
  • 1