[ http://jira.magnolia-cms.com/browse/MAGNOLIA-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27658#action_27658 ]
Philipp Bärfuss commented on MAGNOLIA-3167: ------------------------------------------- {quote}unfortunatelly, the reuqest C will be still blocked and will stay that way forever since removing the mutex{quote} If I understand that right the following will happen if the synchronization block is removed 1) A gets mutext 2) B tries to acquire the mutix 3) C tries to acquire the mutix 4) A releases (calls put) 5) B succeeds but does never release the mutex --> C is blocked for ever Well then we have to find a better solution, just blocking all requests for that reason is not an option. But looking at the following code of net.sf.ehcache.constructs.blocking.BlockingCache.get(Object) (version 1.5) {code} if (element != null) { //ok let the other threads in lock.release(); return element; } else { {code} It seams as if they handle the case in which the cache was populated while that thread was blocked. Either something is very fishy but that extra synchronization block is wrong/obsolete. > cache: single blocking request can block all other requests to cached content > ------------------------------------------------------------------------------ > > Key: MAGNOLIA-3167 > URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3167 > Project: Magnolia > Issue Type: Bug > Components: cache > Affects Versions: 3.6.8, 4.1.4, 4.2.3, 4.3.1 > Reporter: Philipp Bärfuss > Assignee: Boris Kraft > Fix For: 4.3.x > > > 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|http://ehcache.org/apidocs/net/sf/ehcache/constructs/blocking/BlockingCache.html#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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <dev-list-unsubscr...@magnolia-cms.com> ----------------------------------------------------------------