-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cached blocks should be stored per request #101
Comments
@penx This might be hard with the current design of the API. Express doesn't give us the req or res object when render is called. Express render was not really designed with async in mind as it expects all user data to come into the render. I wonder if this library should have never excited with async and forced the programmer to first fetch all data first before calling render but with that said this is what I found looking at this issue. Maybe a better way to solve the memory leak is to use a smarter cache with TTLs. As for the async wrong content are you sure? The library does generate a new ID for each async content request. Let me see if I can create a test that causes this issue. |
Fixed TryGhost#144 registerAsyncHelper using the wrong replace call Fixes TryGhost#143 Update handlebars to 4.0.8 (did latest handlebars) Fixed TryGhost#101 Cached blocks should be stored per request Fixed TryGhost#100 Conflict between content blocks Fixed TryGhost#99 Blocks prone to memory leaks After digging round most of the weekend I fixed the block and sync cache issues by storing them on the options which is setup once per request and passed to everything that needed it. This also fixes the issue with using replace and special strings that can do funny things with JavaScript replace vs using the function version. I also update TravisCI to run the newer node versions for tests and update all the dependencies to the latest versions.
The cached blocks object should be specific to each request, rather than a singleton shared by all requests. After a request has completed, the object can then be removed from memory, ensuring no memory leaks are created. In addition it would prevent conflicts between simultaneous page loads that are using async helpers.
This would resolve issues #99 and #100
The text was updated successfully, but these errors were encountered: