[quote]1- Why does Magnolia refuse to cache big files? And how big is big exactly? 2- What is the problem in caching big files in the first place? Is this an Ehcache limitation or something else? We would still like to cache them (if feasible) because else for every request this file needs to be retrieved from the database (we have externalBLOBs set to false). [/quote] Caching is used to remove overhead of accessing repo and generating html from content + template + model. When serving big files, there's no overhead to generate anything and overhead of accessing repo is negligible in comparison to total time necessary to serve the file. Plus if you have datastore configured, chances are that file is already in the filesystem anyway. ... so much for logical arguments, there's also technical one - ehCache entry is byte array so if we cached big files we would need to have enough memory to get byte array representing such cached big file in memory.
[quote]Is this a configuration somewhere?[/quote] Default threshold is 500* 1024 bytes and is set by info.magnolia.module.cache.executor.Store executor. You would need to extend this class to change the value. [quote]3- What you describe is not what we see happening. No user ever gets to see the file in question. Magnolia never seems to be able to cache the item in question nor mark it for being non-cacheable as you say. The only solution we could think of was to put the file in question on the filesystem and serve it using a special Apache rule as Magnolia simply refuses to serve it. Disabling the cache however does seem to work. [/quote] There could be number of reasons for this. Often it is related to the fact that Magnolia would by default cache also other then 200 responses so if an error occurred while generating original entry, on next try response would be the same w/o trying to produce proper output again. Also often custom 404 pages are set w/ cache headers so browser doesn't really retry to get the resource again. Or it could be something else altogether. Could you re-run your test w/ cache flushed on the public instance, make sure you access it w/o any proxies in between and then provide results and logs? Can you emulate three situations - first user successfully downloads the whole file and then there is number of multiple concurrent requests for same resource. Second user cancels download in the middle and then there is subsequent request for the same resource and third parallel requests for same resource are issues while first user is still downloading the file? [quote]Maybe Openmind's SimpleMedia module would be of help here. At least that would be a central DAM where we can store all media files including the big ones with it's own JCR repo. However even there of course we would like to use the Magnolia cache.[/quote] Whether you choose SimpleMedia or DMS or Data as source of your big files doesn't really matter, you still need to educate your users that there's one place where to store big files and exclude that location from cache. While ago I played with executor that takes the resource URI and then retrieves node that is represented by said URI and uses metadata to find out the size of the resource to see if it could/should be cached or not. Unfortunate side effect of such approach is that it removes one of the main benefits of caching - reducing access to repo. -- Context is everything: http://forum.magnolia-cms.com/forum/thread.html?threadId=aa9ad5f2-5e7e-4ab6-b3c7-921065664420 ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
