4 ms·
> And the problem here wasn't JSON in the first place anyway Yes it was. They stored state in a huge JSON dump which ended up working like a zip bomb by the wa
by simplotek 3y ago
> And the problem here wasn't JSON in the first place anyway
Yes it was. They stored state in a huge JSON dump which ended up working like a zip bomb by the way they had to escape a string. This alone resulted in an exponential increase in memory that quickly became a problem.
Think about it for a second: would they experience this issue if they stored an in-memory stack per user? They wouldn't.
Heck, it seems that they could live with their JSON choice if they replaced '/' with any other inescapable character and converted it back to '/' when reading.
- xigoi 3y agoXML would also have a problem with this: you'd replace < with <, then with &lt;, then with &amp;lt;, … It's not exponential, but still inefficient.
- simplotek 3y agoInefficient is not the same as problematic. They turned what otherwise would be a linear increase in memory usage into an exponential increase, which expectedly resulted in memory exhaustion problems. There are plenty of problems to go around this approach and overall system design, but the weakest link is undoubtedly how JSON was used.