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.2
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.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.nuxeo.com/secure/Administrators.jspa
-
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
