-
Bug
-
Resolution: Fixed
-
Major
-
3.6.8, 4.1.4, 4.2.3, 4.3.1
-
None
the cache mechanism can block all requests:
- cache.get() will block if an other request is caching the same key (this is a feature of the BlockingCache)
- mutex per key kept until cache.put() is called (either with an entry or null value)
- this code is again in a synchronized block which synchronizes on the cache object itself
- this blocks all other request trying to enter the synchronization block
The critical scenario which can prevent magnolia from responding any request (all threads blocked) is the following
1) first request to a resource which is slow or never returns (request to a service, poor database connection, ..)
2) second request to the same resource: --> thread is blocked at EhCacheWrapper.get(key):56, but also keeps the lock on the cache
3) all other caching requests are blocked (no matter which url) due to the synchronize block at Default.shouldCache(Cache, AggregationState, FlushPolicy):89
Solution:
- don't synchronize on the cache (why are we doing this???)
- allow configuration of BlockingCache.timeoutMillis
- throw an exception if a request waits for to long
- uncomment finally block at doFilter(HttpServletRequest, HttpServletResponse, FilterChain), this is a safety net and should log a FATAL ERROR message
- only relevant if the result is a store request
- is depended upon by
-
MGNLADVCACHE-15 Remove synchronized blocks
- Closed
- is related to
-
MAGNOLIA-3333 cache: improve logging on blocking timeouts and unlock in the cache filter on exceptions
- Closed
-
MGNLCACHE-36 Failure to generate response first time might lead to page not being accessible w/o restart
- Closed