[ https://jira.nuxeo.com/browse/NXP-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thierry Delprat updated NXP-6617: --------------------------------- Fix Version/s: (was: 5.4.2) 5.4.3 > Remove EJB3 usage in JBoss 5 packaging > -------------------------------------- > > Key: NXP-6617 > URL: https://jira.nuxeo.com/browse/NXP-6617 > Project: Nuxeo Enterprise Platform > Issue Type: Task > Affects Versions: 5.4.1 > Reporter: Thierry Delprat > Fix For: 5.4.3 > > > Using simple POJO instead of EJB on JBoss5 is the way to reach the > same tomcat performance on repository read ! > Using admin center document statistics we jump from 617 to 2100 doc/s. > When using EJB the document statistics generates around 300 EJB > creation of SFSL DocumentManagerBean. > I need to run more bench on this instance to see if the memory > footprint is smaller and if the web access is faster. > Here are a list of JBoss AS 5.0.1 performance problems: > 1/ A memory leak in VFS > This is a system leak the process is growing taking more and more > RSS and VSZ size, the problem can be seen using pmap and looking at > the number of chunk of 1024K. > I need to perform a long bench to see if the leak reach a limit or > not. > Anyway having lots of memory is enough as a workaround. > https://jira.jboss.org/browse/JBVFS-159 > http://bugs.sun.com/view_bug.do?bug_id=6735255 > 2/ A very slow EJB deployment > The implementation is buggy in 5.0.1 taking a lot of memory. > Even with the latest patch it will never be as fast as JBoss4 EJB > container because it is looking for annotations on methods through > AOP and it seems very slow. > This has an impact as we have 37 EJB on Nuxeo DM. > https://jira.jboss.org/browse/EJBTHREE-1800 > http://community.jboss.org/thread/104679?tstart=0 > 3/ A weird EJB object pool > EJB thread are the same as HTTP (or AJP), Stateless Session and > Stateful Session Beans use the ThreadLocalPool, which is backed by > an InfinitePool with no maximum size, this remove need of lock > access. > The default timeout is 10s for SLSB so I think the pool is useless > most of the time and if you have an http maxThread set to 200 (the > default) this means that you have 200 ejb pools -> buy some more ram > AFAIU there is no way to have a limited pool of EJB like in JBoss4 > using StrictPool will be blocking when reaching the maximum (instead > of sharing a fixed number of object between threads). > http://docs.jboss.org/ejb3/docs/reference/build/reference/en/html/session-bean-config.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ ECM-tickets mailing list ECM-tickets@lists.nuxeo.com http://lists.nuxeo.com/mailman/listinfo/ecm-tickets