Why
While working on the hydra-doom project, we noticed that the in memory state grew without bound (see #1572). This meant that, at the sustained load that the hydra doom demo was producing, nodes became inoperable after just a few hours.
One of the culprits was the ?history of the hydra-node websocket API. That feature sends clients the whole history by default (can be turned off, see documentation https://hydra.family/head-protocol/docs/api-behavior#replay-of-past-server-outputs)
We want to make Hydra heads be operable for long times even with sustained load, which requires us to bound any memory usage (and even disk usage, see #1581).
What
- The default behavior of the websocket API is to not send the whole history, but only the
Greetings message.
- This breaking change is to be communicated properly
- The API server history, if requested by
?history=true, is loaded on-demand from disk.
How
Why
While working on the hydra-doom project, we noticed that the in memory state grew without bound (see #1572). This meant that, at the sustained load that the hydra doom demo was producing, nodes became inoperable after just a few hours.
One of the culprits was the
?historyof thehydra-nodewebsocket API. That feature sends clients the whole history by default (can be turned off, see documentation https://hydra.family/head-protocol/docs/api-behavior#replay-of-past-server-outputs)We want to make Hydra heads be operable for long times even with sustained load, which requires us to bound any memory usage (and even disk usage, see #1581).
What
Greetingsmessage.?history=true, is loaded on-demand from disk.How
hydra-nodesuch that theAPIServeris an interpreter ofStateEventstream #1717