[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3519) Excessive JNDI lookups for "java:comp/UserTransation"
by Jay Balunas (JIRA)
Excessive JNDI lookups for "java:comp/UserTransation"
-----------------------------------------------------
Key: JBSEAM-3519
URL: https://jira.jboss.org/jira/browse/JBSEAM-3519
Project: Seam
Issue Type: Bug
Components: Core, Performance and Scalability
Affects Versions: 2.1.0.CR1
Reporter: Jay Balunas
Assignee: Shane Bryzak
Priority: Critical
Fix For: 2.1.1.CR1
NOTE: There are more details to this on the seam-dev email list and its archives. Below is the primary email that broke down the behavior.
A single user making a single request to the Seam wiki example's user forum front page performs 114 JNDI lookups for "java:comp/UserTransation". This means that not only are 144 instances of IntialContext created, but we have 114 actual lookups as well. This is nearly linear with 2 requests creating 228 JNDI lookups + some for ajax4jsf caching calls as described below. Extrapolating to the 25 user test that would be 25x114=2850 jndi lookups for each round of requests.
At least for the wiki page I am testing there were no other JNDI lookups.
Who is looking up "java:comp/UserTransation"
--------------------------------------------------------
All of these calls can be traced to Transaction.instance(). I broke down all of the calls to Transaction.instance() during a single request to the user forum page on the wiki.
81 - seam.util.Work.workInTransaction(Work.java:34) via (TransactionInterceptor.java:34)
1 - SeamPhaseListener.handleTransactionsBeforePhase(SeamPhaseListener.java:319)
3 - SeamPhaseListener.begin(SeamPhaseListener.java:591)
3 - SeamPhaseListener.begin(SeamPhaseListener.java:594)
3 - SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:611)
3 - SeamPhaseListener.commitOrRollback(SeamPhaseListener.java:614)
8 - ManagedPersistenceContext.joinTransaction(ManagedPersistenceContext.java:120)
6 - Contexts.flushAndDestroyContexts(Contexts.java:331)
6 - ManagedPersistenceContext.close(ManagedPersistenceContext.java:192)
-------------
114 - Total
I then broke it down by which JSF lifecycle phase it was done in.
Phase Breakdown:
------------------
3 - During RESTORE_VIEW
2 - Between RESTORE_VIEW and RENDER_RESPONSE
91 - During RENDER_RESPONSE
18 - After RENDER_RESPONSE
----------
114 total
I then did the same break down on a second follow up request with the same session
Second Request showed a different distribution:
------------------------------------------------
3 - During RESTORE_VIEW
2 - Between RESTORE_VIEW and RENDER_RESPONSE
91 - During RENDER_RESPONSE
5 - After RENDER_RESPONSE
3 - During 2nd RESTORE_VIEW
0 - Between 2nd RESTORE_VIEW and RENDER_RESPONSE
1 - During 2nd RENDER_RESPONSE
3 - After 2nd RENDER_RESPONSE
3 - During 3rd RESTORE_VIEW
0 - Between 3rd RESTORE_VIEW and RENDER_RESPONSE
1 - During 3rd RENDER_RESPONSE
16 - After 3rd RENDER_RESPONSE
------------
128 total
The extra 14 lookups are all during the extra 2 mini requests. They all pass through this ajax4jsf class "org.ajax4jsf.resource.ResourceLifecycle.invokePhaseListener(ResourceLifecycle.java:[199/201])". I'm assuming that these extra calls are related to page fragment caching and/or resources that are provided through the ajax4jsf InternetResourceService. Christian can you confirm?
Conclusions:
---------------------
We obviously need to find more ways to improve this behavior. The primary offender is "Work.java" (see: http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/W... ). This single line is checking if the transaction is currently active. 81 time it is active and processing continues as normal. Is there a way we can cache this value for the length of the request (either the transaction, or the result)? Caching the result could be bad if something changed during the request, so we would need the actual transaction.
Also many of the lookups were the result of EL processing during the RENDER_RESPONSE phase. Ideally these would primarily be read-only requests or close to it. Could there be a way to disable the transactional calls for items somehow tagged read only? I have not give that much thought yet so it might need some flushing out ;-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3485) Optimize how the InitialContext is created in org.jboss.seam.util.Naming
by Jay Balunas (JIRA)
Optimize how the InitialContext is created in org.jboss.seam.util.Naming
------------------------------------------------------------------------
Key: JBSEAM-3485
URL: https://jira.jboss.org/jira/browse/JBSEAM-3485
Project: Seam
Issue Type: Task
Components: Core
Affects Versions: 2.1.0.BETA1
Reporter: Jay Balunas
Fix For: 2.1.1.CR1
Attachments: patch.txt
Seam currently only creates and manages the InitialContext in the "org.jboss.seam.util.Naming" class (see: http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/util/N... ). The properties are set in one location and done only once during the initialization of seam (see: http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/init/I... ).
I see two issues here although they are related.
The first issue would require some caching mechanism or logic for reuse of the InitialContext instance instead of recreating it every time. WE need to determine when it makes sense to reuse an instance of the InitialContext, and when we need to get it fresh. We currently use they exact same properties to initialize it and those are set during Seam initialization and do not appear to ever change once created.
The second issue is that we do a certain amount of processing every time the context is requested, this could be optimized. Currently I see a few blocked threads on the "props.size()" call in the Naming class which is a synchronized method on the Hashtable. We need to maintain the logic that if the property list is empty we continue to call "new InitialContext()" and not pass in the properties object. This is because the first thing the InitialContext constructor does with a properties object is clone it which can be costly. This change is not as important if we find a way to cache the initial context. I have attached a patch that implements these changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3609) Performance problem: when using <s:link> or <s:button> with page.xml
by kun zhang (JIRA)
Performance problem: when using <s:link> or <s:button> with page.xml
--------------------------------------------------------------------
Key: JBSEAM-3609
URL: https://jira.jboss.org/jira/browse/JBSEAM-3609
Project: Seam
Issue Type: Bug
Affects Versions: 2.0.3.CR1, 2.0.2.SP1
Environment: JDK 1.5.0_14, jboss-4.2.3.GA
Reporter: kun zhang
Priority: Critical
<s:link> or <s:button> will automatically check the View_id's page.xml, and temporary construct the seam components in the page.xml, then call component's @Create and @Destroy method.
For example:
There is a <s:link> at the menu.xhtml:
<s:link view="/login.xhtml" value="Login"/>
If login.page.xhtml like this:
<param name="order" value="#{deptList.order}"/>
seam will automatically construct the deptList component, and call it's @Create and @Destroy method.
I find the issue at Seam 2.0.2.SP1 and 2.0.3.CR1.
It's a big performance problem, please resolve it ASAP.
Thanks a lot and sorry for my bad english.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2704) Performance during iteration (datatable, repeat) in the UI with value bindings that run through interceptors
by Siarhei Dudzin (JIRA)
Performance during iteration (datatable, repeat) in the UI with value bindings that run through interceptors
------------------------------------------------------------------------------------------------------------
Key: JBSEAM-2704
URL: http://jira.jboss.com/jira/browse/JBSEAM-2704
Project: JBoss Seam
Issue Type: Bug
Components: Performance and Scalability
Affects Versions: 2.0.1.GA, 2.0.0.GA
Environment: Seam 2.0.0, 2.0.1
Reporter: Siarhei Dudzin
"Since we don't cache this, a particular backing bean might be called hundreds or thousands of times during rendering of a datatable, if a value binding has to be evaluated for each row. If the backing bean is a Seam component, injection of dependencies will occur for every call, involving potentially thousands of map lookups."
There is a discussion thread with a bit more data: http://www.seamframework.org/Community/SeamPerformanceOptimization
The issue is also recognized at the seamframework.org site itself: http://www.seamframework.org/Documentation/TuningTheSeamWebsite#H-Iterati...
Since the issue it known, this JIRA report is created for better traceability.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 5 months