3:57 a.m.
High CPU Utilization in Richfaces application
---------------------------------------------
Key: RF-10998
URL: https://issues.jboss.org/browse/RF-10998
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.3.2.SR1
Environment: Jboss 4.3.0.GA_CP03, jdk 1.6.0_05,jsf 1.2,facelets 1.1.14
Reporter: Shah EM
We have an application running on 3 node
cluster.After running normally for some time one node CPU spikes to 80% from
the normal usage of 6% and stays like that. meanwhile other nodes are working
fine.
We had contacted Redhat and they had advised to downgrad richfaces version to 3.3.1 sp2 to
fix the issue.
We have a doubt if the solution provided by Redhat to downgrade the rich faces version to
3.3.1-SP2 will solve the issue or not.
The 3.3.1-SP2 release note says that the following issue is fixed - [RF-7248] - a4j
creates infinite HashMap.get loop
When we looked into more details of this issue that they fixed in the JBoss JIRA for this
defect, the logs say that the issue is with a specific component in the a4j. Please have a
look at the following trace from the issue logs.
Stack trace:
java.util.HashMap.get(HashMap.java:303)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:965)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:984)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:943)
In our case even though the issue is with the HashMap infinite loop, the cause of the
issue does not seem to be this particular component. Our stack traces point to a different
place where the infinite loop is happening.
Thread: http-10.20.81.200-17180-31 : priority:5, demon:true, threadId:337,
threadState:RUNNABLE, lockName:null
java.util.HashMap.get(HashMap.java:305)
org.apache.catalina.connector.Request.getAttribute(Request.java:878)
org.apache.catalina.connector.RequestFacade.getAttribute(RequestFacade.java:263)
com.sun.faces.application.WebappLifecycleListener.attributeReplaced(WebappLifecycleListener.java:168)
com.sun.faces.config.ConfigureListener.attributeReplaced(ConfigureListener.java:318)
org.apache.catalina.connector.Request.setAttribute(Request.java:1435)
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:284)
com.sun.faces.context.RequestMap.put(ExternalContextImpl.java:1087)
org.ajax4jsf.event.AjaxPhaseListener.afterPhase(AjaxPhaseListener.java:81)
com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:16 p.m.
New subject: [JBoss JIRA] Updated: (RF-10998) High CPU Utilization in Richfaces application
[
https://issues.jboss.org/browse/RF-10998?page=com.atlassian.jira.plugin.s...
]
Jay Balunas updated RF-10998:
-----------------------------
Fix Version/s: 3.Future
High CPU Utilization in Richfaces application
---------------------------------------------
Key: RF-10998
URL: https://issues.jboss.org/browse/RF-10998
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.3.2.SR1
Environment: Jboss 4.3.0.GA_CP03, jdk 1.6.0_05,jsf 1.2,facelets 1.1.14
Reporter: Shah EM
Labels: richfaces
Fix For: 3.Future
We have an application running on 3 node
cluster.After running normally for some time one node CPU spikes to 80% from
the normal usage of 6% and stays like that. meanwhile other nodes are working
fine.
We had contacted Redhat and they had advised to downgrad richfaces version to 3.3.1 sp2
to fix the issue.
We have a doubt if the solution provided by Redhat to downgrade the rich faces version to
3.3.1-SP2 will solve the issue or not.
The 3.3.1-SP2 release note says that the following issue is fixed - [RF-7248] - a4j
creates infinite HashMap.get loop
When we looked into more details of this issue that they fixed in the JBoss JIRA for this
defect, the logs say that the issue is with a specific component in the a4j. Please have a
look at the following trace from the issue logs.
Stack trace:
java.util.HashMap.get(HashMap.java:303)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:965)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:984)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:943)
In our case even though the issue is with the HashMap infinite loop, the cause of the
issue does not seem to be this particular component. Our stack traces point to a different
place where the infinite loop is happening.
Thread: http-10.20.81.200-17180-31 : priority:5, demon:true, threadId:337,
threadState:RUNNABLE, lockName:null
java.util.HashMap.get(HashMap.java:305)
org.apache.catalina.connector.Request.getAttribute(Request.java:878)
org.apache.catalina.connector.RequestFacade.getAttribute(RequestFacade.java:263)
com.sun.faces.application.WebappLifecycleListener.attributeReplaced(WebappLifecycleListener.java:168)
com.sun.faces.config.ConfigureListener.attributeReplaced(ConfigureListener.java:318)
org.apache.catalina.connector.Request.setAttribute(Request.java:1435)
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:284)
com.sun.faces.context.RequestMap.put(ExternalContextImpl.java:1087)
org.ajax4jsf.event.AjaxPhaseListener.afterPhase(AjaxPhaseListener.java:81)
com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:16 p.m.
New subject: [JBoss JIRA] Commented: (RF-10998) High CPU Utilization in Richfaces application
[
https://issues.jboss.org/browse/RF-10998?page=com.atlassian.jira.plugin.s...
]
Jay Balunas commented on RF-10998:
----------------------------------
Hi Shah,
It appears your are using our enterprise software (EAP). EAP subscription also includes
entitlement for full support on all of the technologies included.
Your issues will be resolved much faster if you work through our professional support
team. I recommend you login to our customer support portal and file a support ticket. You
will be connected with one of our experts who can help you resolve this issue.
Here is the link to our customer support portal - https://access.redhat.com/home
Thanks,
Jay
High CPU Utilization in Richfaces application
---------------------------------------------
Key: RF-10998
URL: https://issues.jboss.org/browse/RF-10998
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.3.2.SR1
Environment: Jboss 4.3.0.GA_CP03, jdk 1.6.0_05,jsf 1.2,facelets 1.1.14
Reporter: Shah EM
Labels: richfaces
Fix For: 3.Future
We have an application running on 3 node
cluster.After running normally for some time one node CPU spikes to 80% from
the normal usage of 6% and stays like that. meanwhile other nodes are working
fine.
We had contacted Redhat and they had advised to downgrad richfaces version to 3.3.1 sp2
to fix the issue.
We have a doubt if the solution provided by Redhat to downgrade the rich faces version to
3.3.1-SP2 will solve the issue or not.
The 3.3.1-SP2 release note says that the following issue is fixed - [RF-7248] - a4j
creates infinite HashMap.get loop
When we looked into more details of this issue that they fixed in the JBoss JIRA for this
defect, the logs say that the issue is with a specific component in the a4j. Please have a
look at the following trace from the issue logs.
Stack trace:
java.util.HashMap.get(HashMap.java:303)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:965)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:984)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:943)
In our case even though the issue is with the HashMap infinite loop, the cause of the
issue does not seem to be this particular component. Our stack traces point to a different
place where the infinite loop is happening.
Thread: http-10.20.81.200-17180-31 : priority:5, demon:true, threadId:337,
threadState:RUNNABLE, lockName:null
java.util.HashMap.get(HashMap.java:305)
org.apache.catalina.connector.Request.getAttribute(Request.java:878)
org.apache.catalina.connector.RequestFacade.getAttribute(RequestFacade.java:263)
com.sun.faces.application.WebappLifecycleListener.attributeReplaced(WebappLifecycleListener.java:168)
com.sun.faces.config.ConfigureListener.attributeReplaced(ConfigureListener.java:318)
org.apache.catalina.connector.Request.setAttribute(Request.java:1435)
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:284)
com.sun.faces.context.RequestMap.put(ExternalContextImpl.java:1087)
org.ajax4jsf.event.AjaxPhaseListener.afterPhase(AjaxPhaseListener.java:81)
com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:08 p.m.
New subject: [JBoss JIRA] Commented: (RF-10998) High CPU Utilization in Richfaces application
[
https://issues.jboss.org/browse/RF-10998?page=com.atlassian.jira.plugin.s...
]
Shah EM commented on RF-10998:
------------------------------
Hi,
We have been facing an issue with the Request object in richFaces version and this issue
has been logged under issue number 00479438.The response we got from the support forum was
to try out with Richfaces Enterprise edition (Richfaces 3.3.1.SP2 ) to resolve the issue.
As this is an issue in a production environment, it is not feasible for us to downgrade to
the enterprise edition without considerable effort. Our organisation is moving in the open
source direction, and such a response would not help us further this initiative within the
organisation.
We would really appreciate if you could suggest a solution to resolve the issue.
Regards,
Shah
High CPU Utilization in Richfaces application
---------------------------------------------
Key: RF-10998
URL: https://issues.jboss.org/browse/RF-10998
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.3.2.SR1
Environment: Jboss 4.3.0.GA_CP03, jdk 1.6.0_05,jsf 1.2,facelets 1.1.14
Reporter: Shah EM
Labels: richfaces
Fix For: 3.Future
We have an application running on 3 node
cluster.After running normally for some time one node CPU spikes to 80% from
the normal usage of 6% and stays like that. meanwhile other nodes are working
fine.
We had contacted Redhat and they had advised to downgrad richfaces version to 3.3.1 sp2
to fix the issue.
We have a doubt if the solution provided by Redhat to downgrade the rich faces version to
3.3.1-SP2 will solve the issue or not.
The 3.3.1-SP2 release note says that the following issue is fixed - [RF-7248] - a4j
creates infinite HashMap.get loop
When we looked into more details of this issue that they fixed in the JBoss JIRA for this
defect, the logs say that the issue is with a specific component in the a4j. Please have a
look at the following trace from the issue logs.
Stack trace:
java.util.HashMap.get(HashMap.java:303)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:965)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:984)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:943)
In our case even though the issue is with the HashMap infinite loop, the cause of the
issue does not seem to be this particular component. Our stack traces point to a different
place where the infinite loop is happening.
Thread: http-10.20.81.200-17180-31 : priority:5, demon:true, threadId:337,
threadState:RUNNABLE, lockName:null
java.util.HashMap.get(HashMap.java:305)
org.apache.catalina.connector.Request.getAttribute(Request.java:878)
org.apache.catalina.connector.RequestFacade.getAttribute(RequestFacade.java:263)
com.sun.faces.application.WebappLifecycleListener.attributeReplaced(WebappLifecycleListener.java:168)
com.sun.faces.config.ConfigureListener.attributeReplaced(ConfigureListener.java:318)
org.apache.catalina.connector.Request.setAttribute(Request.java:1435)
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:284)
com.sun.faces.context.RequestMap.put(ExternalContextImpl.java:1087)
org.ajax4jsf.event.AjaxPhaseListener.afterPhase(AjaxPhaseListener.java:81)
com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:21 a.m.
New subject: [JBoss JIRA] Issue Comment Edited: (RF-10998) High CPU Utilization in Richfaces application
[
https://issues.jboss.org/browse/RF-10998?page=com.atlassian.jira.plugin.s...
]
Shah EM edited comment on RF-10998 at 5/29/11 1:19 AM:
-------------------------------------------------------
Hi,
We have been facing an issue with the Request object in richFaces version and this issue
has been logged under issue number 00479438.The response we got from the support forum was
to try out with Richfaces Enterprise edition (Richfaces 3.3.1.SP2 ) to resolve the issue.
As this is an issue in a production environment, it is not feasible for us to downgrade to
the enterprise edition without considerable effort. Our organisation is moving in the open
source direction, and such a response would not help us further this initiative within the
organisation.
We would really appreciate if you could suggest a solution to resolve the issue as this
seems to be going into a stalemate.
The Richfaces version we used is 3.3.2.SR1 based on the specific features availability at
the time of development. However the application server we use is the supported version
(JBOSS eap 4.3). Since this issue is with the supported JBOSS version it doesn't make
sense to give a fix in Richfaces as is claimed by Jboss support.
Your assistance will be really appreciated since the management here is now thinking of
moving to WebLogic. As the effort involved in the regression testing will be the same.
Regards,
Shah
was (Author: s747045):
Hi,
We have been facing an issue with the Request object in richFaces version and this issue
has been logged under issue number 00479438.The response we got from the support forum was
to try out with Richfaces Enterprise edition (Richfaces 3.3.1.SP2 ) to resolve the issue.
As this is an issue in a production environment, it is not feasible for us to downgrade to
the enterprise edition without considerable effort. Our organisation is moving in the open
source direction, and such a response would not help us further this initiative within the
organisation.
We would really appreciate if you could suggest a solution to resolve the issue.
Regards,
Shah
High CPU Utilization in Richfaces application
---------------------------------------------
Key: RF-10998
URL: https://issues.jboss.org/browse/RF-10998
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.3.2.SR1
Environment: Jboss 4.3.0.GA_CP03, jdk 1.6.0_05,jsf 1.2,facelets 1.1.14
Reporter: Shah EM
Labels: richfaces
Fix For: 3.Future
We have an application running on 3 node
cluster.After running normally for some time one node CPU spikes to 80% from
the normal usage of 6% and stays like that. meanwhile other nodes are working
fine.
We had contacted Redhat and they had advised to downgrad richfaces version to 3.3.1 sp2
to fix the issue.
We have a doubt if the solution provided by Redhat to downgrade the rich faces version to
3.3.1-SP2 will solve the issue or not.
The 3.3.1-SP2 release note says that the following issue is fixed - [RF-7248] - a4j
creates infinite HashMap.get loop
When we looked into more details of this issue that they fixed in the JBoss JIRA for this
defect, the logs say that the issue is with a specific component in the a4j. Please have a
look at the following trace from the issue logs.
Stack trace:
java.util.HashMap.get(HashMap.java:303)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:965)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:984)
org.ajax4jsf.component.UIDataAdaptor.restoreChildState(UIDataAdaptor.java:943)
In our case even though the issue is with the HashMap infinite loop, the cause of the
issue does not seem to be this particular component. Our stack traces point to a different
place where the infinite loop is happening.
Thread: http-10.20.81.200-17180-31 : priority:5, demon:true, threadId:337,
threadState:RUNNABLE, lockName:null
java.util.HashMap.get(HashMap.java:305)
org.apache.catalina.connector.Request.getAttribute(Request.java:878)
org.apache.catalina.connector.RequestFacade.getAttribute(RequestFacade.java:263)
com.sun.faces.application.WebappLifecycleListener.attributeReplaced(WebappLifecycleListener.java:168)
com.sun.faces.config.ConfigureListener.attributeReplaced(ConfigureListener.java:318)
org.apache.catalina.connector.Request.setAttribute(Request.java:1435)
org.apache.catalina.connector.RequestFacade.setAttribute(RequestFacade.java:503)
javax.servlet.ServletRequestWrapper.setAttribute(ServletRequestWrapper.java:284)
com.sun.faces.context.RequestMap.put(ExternalContextImpl.java:1087)
org.ajax4jsf.event.AjaxPhaseListener.afterPhase(AjaxPhaseListener.java:81)
com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:175)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:114)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4936
days inactive
4943
days old
richfaces-issues@lists.jboss.org
4 comments
2 participants
participants (2)
-
Jay Balunas (JIRA) -
Shah EM (JIRA)