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: sethfromaust...@gmail.com [mailto:sethfromaust...@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 <ma...@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.baudi...@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 >>> >>> >>>