You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when a client connect (via WebSocket) to a Hydra node, the server replays the entire history of event through the connection. This is meant to allow stateless event-driven clients that can be fully driven by the API. However, as the head grows and lasts, this initial dump can be large and unnecessary for some use-cases where clients are only really interested in the latest events.
This ought to be made optional (perhaps as a response to a specific message, or, when passed a specific sub-protocol to the websocket).
Note that, a side (albeit perhaps more important) concern is that this whole history of event is currently maintained in plain memory, effectively causing a memory leak on the server which has to retain all messages floating inside the head. This thereby relate to and should be fixed by #187.
The text was updated successfully, but these errors were encountered:
ch1bo
changed the title
Don't (always) dump head history on client connection
Configurable latching of message history on client connection
Jun 7, 2022
ch1bo
added
task
Subtask of a bigger feature.
and removed
💭 idea
An idea or feature request
amber ⚠️
Medium complexity or partly unclear feature
labels
Jun 7, 2022
Why & What
Currently, when a client connect (via WebSocket) to a Hydra node, the server replays the entire history of event through the connection. This is meant to allow stateless event-driven clients that can be fully driven by the API. However, as the head grows and lasts, this initial dump can be large and unnecessary for some use-cases where clients are only really interested in the latest events.
This ought to be made optional (perhaps as a response to a specific message, or, when passed a specific sub-protocol to the websocket).
Note that, a side (albeit perhaps more important) concern is that this whole history of event is currently maintained in plain memory, effectively causing a memory leak on the server which has to retain all messages floating inside the head. This thereby relate to and should be fixed by #187.
The text was updated successfully, but these errors were encountered: