myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry Evers (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-1162) _ComponentAttributesMap.getPropertyDescriptor appears to get hung in a HashMap under peak load.
Date Thu, 08 Jun 2006 20:02:31 GMT
    [ http://issues.apache.org/jira/browse/MYFACES-1162?page=comments#action_12415415 ] 

Larry Evers commented on MYFACES-1162:
--------------------------------------


It has been determined that when a user creates a second session using CNTL-N (or other ways)
and sends request from both identical sessions to the application code the requests conflict.
 

In the JSF blueprint and the sample code it shows that the managed beans (the data) and the
control beans (the UI control) are separate beans.  Furthermore, the control bean should be
set to request scope through the faces-config.xml and the managed beans to session scope.

Basically, we put both the data and the control into the same backingBeans for our application
and all are at session scope.  When two sessions are both being processed concurrently the
Myfaces framework is getting hung up in a HashMap that is not thread safe.  This would not
occur if these were request scope.  

I changed my application and have not had a re-occurrence of the hung thread problem.  COde
ha been productive since May 21st.

Thanks to everyone for their input.
Larry

> _ComponentAttributesMap.getPropertyDescriptor appears to get hung in a HashMap under
peak load.
> -----------------------------------------------------------------------------------------------
>
>          Key: MYFACES-1162
>          URL: http://issues.apache.org/jira/browse/MYFACES-1162
>      Project: MyFaces Core
>         Type: Bug

>     Versions: 1.1.1
>  Environment: Solaris: SunOS mkeux507 5.9 Generic_117171-11 sun4u sparc SUNW,Sun-Fire-V440,
Java: 1.4.2_08,  WAS: V5.1.1.6
>     Reporter: Larry Evers
>     Priority: Critical
>  Attachments: native_stdout.log
>
> Our production ECS application (built with WSAD V5.1.2) is running on WAS 5.1.1.6 on
6 (4 processor) Solaris boxes each running 4 VM's for a total of 24 app server instances.
 Each App server is tied directly to a web server (IBMHTTPD).  A load balancer at the front
selects the web server to use based on equal weighting.  We are not using session clustering
so if an app server fails the transaction is lost.
> Our application is a JSF application running Apache myfaces V1.1.1.
> Under peak load we appear to get threads hung.  As more threads get hung the cpu usage
goes up on the box, eventually reaching 100%.
> We stopped the web server for this app server so no new activity would hit the app server.
> We then did a series of kill -3 to see what the threads were doing.  CPU stayed high.
> 8 transport threads (341, 339, 8, 7, 6, 5, 3, 2) appear to be hung in a HashMap for each
kill -3.
> Sample output of native_stdout.log (attached)
> "Servlet.Engine.Transports : 339" daemon prio=5 tid=0x0049ba38 nid=0x74c0 runnable [cdcfb000..cdcffc28]
> 	at java.util.HashMap.put(HashMap.java:382)
> 	at javax.faces.component._ComponentAttributesMap.getPropertyDescriptor(_ComponentAttributesMap.java:203)
> 	at javax.faces.component._ComponentAttributesMap.get(_ComponentAttributesMap.java:124)
> 	at javax.faces.webapp.UIComponentTag.removeFormerChildren(UIComponentTag.java:268)
> 	at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:241)
> 	at org.apache.jsp._cardStatus._jspService(_cardStatus.java:4020)
> 	at com.ibm.ws.webcontainer.jsp.runtime.HttpJspBase.service(HttpJspBase.java:89) ....truncated

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message