[
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: <[email protected]>
----------------------------------------------------------------
