You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Larry Evers (JIRA)" <de...@myfaces.apache.org> on 2006/06/08 22:02:31 UTC
[jira] Commented: (MYFACES-1162)
_ComponentAttributesMap.getPropertyDescriptor appears to get hung in a
HashMap under peak load.
[ 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