Hello Martin, 3) if you don't need to replicate the ViewState in a cluster then you can use a own StateManager without informing the container that the ViewStateMap has changed.
4) if org.apache.myfaces.CONFIG_REFRESH_PERIOD=0 is configured we can use an unsynchronized version. But org.apache.myfaces.CONFIG_REFRESH_PERIOD=0 must configured for all webapps that shared this MyFaces class. Regards Bernd On Wed, Jul 27, 2011 at 9:20 PM, Martin Koci <[email protected]> wrote: > Hi, > > I'm doing some profiling for a view, where thousand of concurrent users > is planned. Configuration myfaces trunk, juel, tomcat 6.0.26, OWB trunk > > Here are the top blocking locks: > > 1) java.util.Collections$SynchronizedMap.get(Object) > de.odysseus.el.tree.impl.Cache.get(String) > > 2)java.beans.PropertyDescriptor.getReadMethod() > javax.el.BeanELResolver$BeanProperty.getReadMethod() > > 3)org.apache.catalina.core.ContainerBase.fireContainerEvent(String, > Object) > .... > org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(String, > Object)... > ... ServerSideStateCacheImpl.saveSerializedViewInServletSession > > 4)javax.faces.FactoryFinder._getFactory(String) > javax.faces.FactoryFinder.getFactory(String) > org.apache.myfaces.context.servlet.FacesContextImplBase.getRenderKit() > > ad 1 and 2) - those come from JUEL. The first one I try to avoid with > [1] and second one with [2] as Mark Struberg suggested. ( why JUEL uses > SynchronizedMap, not ConcurrentHashMap ?) > > > > 3) and 4) are from myfaces - any ideas if they can be avoided? > > Regards, > > Kočičák > > > [1] https://issues.apache.org/jira/browse/MYFACES-3160 > [2] > https://github.com/struberg/juel/commit/da3791b91c3e23c973ee865050846b980399ecff > > > > >
