[
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
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
