hmm, perhaps another thing that needs to be documented somewhere ... What happens is that very first time when thread/client requests particular cacheable url, magnolia creates this lock and starts generating the output data for the resource. Any other thread/client requesting same cacheable url will just wait until the first one is done to prevent situation where multiple clients would perform DOS attack on server by requesting url that is expensive to produce. The smaller and easier to generate page, the smaller congestion window. The heavier page, the higher likelihood that 2nd requests come while 1st one is still being executed. Timeout is just a safety net that threads do not wait forever in case the first one doesn't finish (for whatever reason). When timeout occurs the lock is forcibly released, all waiting resources are also released and get the error. I guess you might argue that you want to re-try in this situation, but ... - those clients were already waiting for while to get the response - the chances are this was not a random failure (in sense of unexpected termination w/o lock release) and it will happen again - in case there was no failure but the original thread is stuck in endless loop you don't really want to waste another thread - in case the server is so busy that it was not able to serve the request in given time, failing additional requests rather then re-trying blindly will off load or delay this until client requests again - client gets response as soon as possible, even if it is a response that server is not able to serve the resource at this time, but at least it doesn't hang leaving client unsure of what is going on.
HTH, Jan On Nov 16, 2010, at 1:17 PM, Nils Breunese wrote: > > Jan Haderka wrote: > >> not much of a fix, but if you need to increase timeout you can set >> "blockingTimeout" on >> config:/modules/cache/config/cacheFactory/defaultCacheConfiguration >> the value is in miliseconds. > > Thanks for that. To my (untrained) eye it sounds like acquiring a lock for a > cache key should be a simple process and that 4000 ms should be way enough > time for that. Did you encounter any situations before in which this timeout > needed to be raised? If so, to what values? Does it make sense that the > 'weight' of a page (lots of content, external images, etc.) seems to be a > factor here (I don't see how just yet), or is that just a coincidence? > > Nils. > ------------------------------------------------------------------------ > VPRO > phone: +31(0)356712911 > e-mail: [email protected] > web: www.vpro.nl > ------------------------------------------------------------------------ > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- - Best regards, Jan Haderka, PhD. Magnolia International Ltd. http://www.magnolia-cms.com http://twitter.com/magnolia_cms http://facebook.com/Magnolia -------------------------------------- Magnolia® - Simple Open-Source Content Management ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
