Consider improvements to SockJS message cache [SPR-11183]

[spring-projects-issues]

Rossen Stoyanchev opened SPR-11183 and commented

The cache is intended to buffer messages in the period when one HTTP streaming/polling connection ends and before the client open another one (a very brief period of time usually).

Currently if the buffer is full an IllegalStateException results. Instead we could block the message sending thread pushing the overload back to the consumer.

---

Affects: 4.0 RC2

Referenced from: commits c1f3da0

[spring-projects-issues]

Rossen Stoyanchev commented

See also discussion here.

[spring-projects-issues]

Rossen Stoyanchev commented

SockJS HTTP transports use successive long running requests to send or stream messages to the client. Between successive requests, when the SockJS sessions is effectively inactive, it is not possible to send messages to the client, and therefore server-to-client messages must be cached.

The message cache size can be configured in both XML namespace and Java config. If the cache size limit is reached, the session is closed. This behavior will remain as is. The alternative of blocking the sender of the messages is not effective since the sender may have passed the message asynchronously (e.g. through a MessageChannel).

The specific scenario prompting this ticket is a client sending 20K messages where the server-side WebSocketHandler echoes them back. Blocking for any amount of time when the message cache fills up is of no use in this case and actually leads to a deadlock. Increasing the message cache size does solve the case or alternatively one could impose limits on the number of messages sent in a short period of time.

[spring-projects-issues]

Rossen Stoyanchev commented

Resolving as "Complete" since investigations did lead to addressing an implementation issue (see commit).