Hello Mario and Jakob,
thank you very much for your ideas on this problem.
As far as I understood, the map that is causing the trouble is initialized
inside class RedirectTrackerManager, and not by the application container:
protected Map getRequestBeanMap()
{
if (requestBeanMap == null)
{
requestBeanMap = new TreeMap();
}
return requestBeanMap;
}
so what do you think of using a concurrent counterpart of TreeMap instead, e.g.
java.util.concurrent.ConcurrentSkipListMap?
Best regards,
-- Jan
Am 10.12.2009 um 11:08 schrieb Mario Ivankovits:
> Ja, a ConcurrentMap might do the trick, but the thing is, this is out of our
> scope, isn't it?
>
> These maps are create by the servlet container and thus are part of the
> servlet spec. And even then, they are created by tomcat.
>
> I am afraid, there is nothing we can do.
> As far as I remember, there was about a discussion about synchronizing
> against those map in the servelt container. But this has been abandoned for
> performance reasons.
>
> Ciao,
> Mario
>
>> -----Ursprüngliche Nachricht-----
>> Von: [email protected] [mailto:[email protected]] Im
>> Auftrag von Jakob Korherr
>> Gesendet: Donnerstag, 10. Dezember 2009 10:35
>> An: MyFaces Discussion
>> Betreff: Re: 100% CPU Usage and blocking concurrent Threads when using
>> t:saveState
>>
>> I agree with Mario. It really seams llike the internal structure of the
>> TreeMap is destroyed, thus ending in some infinite loop and causing
>> 100%
>> CPU.
>>
>> Shouldn't we generally synchronize those Maps or use ConcurrentMaps?
>>
>> Regards,
>>
>> Jakob Korherr
>>
>> 2009/12/10 Mario Ivankovits <[email protected]>
>>
>>> For me, this clearly looks like concurrent usage of the request
>> map.
>>>
>>> All the servlet scopes (session, request, …) are not thread safe and
>> one
>>> has to assure that they are not accessed at the same time by multiple
>>> threads.
>>>
>>>
>>>
>>> This turns out to be hard as e.g. there is no "standard" how to
>> synchronize
>>> against the session map. As a side note: I often wonder why this does
>> not
>>> lead to much more problems in the wild …
>>>
>>>
>>>
>>> Anyway, in your case it seems the internal datastructure of the
>> request map
>>> is damaged - which in fact is strange as I do not know when the
>> request map
>>> will be accessed by multiple threads.
>>>
>>>
>>>
>>> Sorry that this is not a solution, but it should give you a clue
>> where to
>>> look next …
>>>
>>>
>>>
>>> Ciao,
>>>
>>> Mario
>>>
>>>
>>>
>>> *Von:* Jan Baudisch [mailto:[email protected]]
>>> *Gesendet:* Donnerstag, 10. Dezember 2009 08:02
>>> *An:* MyFaces Discussion
>>> *Betreff:* 100% CPU Usage and blocking concurrent Threads when using
>>> t:saveState
>>>
>>>
>>>
>>> Hello MyFaces Community,
>>>
>>>
>>>
>>> we are using MyFaces 1.2.0 with Tomahawk Sandbox 1.1.5 and have the
>>> problem, that once in a while we get 100% CPU Usage and blocking
>> concurrent
>>> threads because of using t:saveState
>>>
>>>
>>>
>>> A thread dump shows that the threads always stops at
>>>
>>>
>>>
>>> at java.util.TreeMap.put(TreeMap.java:545)
>>>
>>> at
>>>
>> org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSav
>> eStateBean(RedirectTrackerManager.java:306)
>>>
>>> at
>>>
>> org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolv
>> er.resolveVariable(RedirectTrackerVariableResolver.java:50)
>>>
>>>
>>>
>>> (The complete thread dump is attached). The problem shows up on one
>> system
>>> with heavy concurrent usage and JxBrowser as client.
>>>
>>>
>>>
>>> After we kill these threads using Lambda Probe, the CPU Usage
>> normalizes.
>>>
>>>
>>>
>>> The problem occurs in that method:
>>>
>>>
>>>
>>> ...
>>>
>>> public void addSaveStateBean(String expressionString, Object
>> value)
>>>
>>> {
>>>
>>> if(log.isDebugEnabled())
>>>
>>> log.debug("addSaveStateBean: " + expressionString + "
>> value=" +
>>> value);
>>>
>>> requestBeanMap.put(expressionString, value);
>>>
>>> }
>>>
>>> ...
>>>
>>> private final Map requestBeanMap = new TreeMap(); ...
>>>
>>>
>>>
>>> As the problem is really severe for us, any hints are highly
>> appreciated.
>>>
>>>
>>>
>>> Many thanks in advance,
>>>
>>> -- Jan
>>>
>>>
>>>
