myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Baudisch <jan.baudi...@gmx.net>
Subject Re: 100% CPU Usage and blocking concurrent Threads when using t:saveState
Date Thu, 10 Dec 2009 10:57:32 GMT
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: sethfromaustria@gmail.com [mailto:sethfromaustria@gmail.com] 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 <mario@ops.co.at>
>> 
>>>  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:jan.baudisch@gmx.net]
>>> *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
>>> 
>>> 
>>> 


Mime
View raw message