Ah ... ok, sorry, didn't remember exactly. Ok, this changes things.

Yes, synchronizing in one way or the other might help here.

The ConcurrentSkipListMap is JDK 1.6 only, so might not make it as patch
into myfaces, but a simple synchronize() around each requestBeanMap access
might do the trick either. I do not suspect that you notice any performance
loss.

Please try and report back!

Ciao,
Mario


> -----Ursprüngliche Nachricht-----
> Von: Jan Baudisch [mailto:jan.baudi...@gmx.net]
> Gesendet: Donnerstag, 10. Dezember 2009 11:58
> An: MyFaces Discussion
> Betreff: Re: 100% CPU Usage and blocking concurrent Threads when using
> t:saveState
> 
> 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
> >>>
> >>>
> >>>
> 
> really severe for us, any hints are highly
> >> appreciated.
> >>>
> >>>
> >>>
> >>> Many thanks in advance,
> >>>
> >>> -- Jan
> >>>
> >>>
> >>>

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to