[JBoss JIRA] (RF-12033) ExtendedDataTable doesn't show up in tabpanel with switchType="client"
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-12033?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak reassigned RF-12033:
----------------------------------
Assignee: Jiří Štefek (was: Pavol Pitonak)
> ExtendedDataTable doesn't show up in tabpanel with switchType="client"
> ----------------------------------------------------------------------
>
> Key: RF-12033
> URL: https://issues.jboss.org/browse/RF-12033
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.2.0.Final
> Environment: FireFox 10.0.2 (works in IE7)
> GlassFish 3.1
> Reporter: Josh Hill
> Assignee: Jiří Štefek
> Labels: lazy-loaded
> Attachments: richfaces-test.zip
>
>
> ExtendedDataTable doesn't show up in tabpanel with switchType="client"
> Facelet file from the attached testcase:
> {code}
> <?xml version='1.0' encoding='UTF-8' ?>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:rich="http://richfaces.org/rich"
> xmlns:f="http://java.sun.com/jsf/core">
> <h:head>
> <title>Test One</title>
> </h:head>
> <h:body>
> <p>Extended datatable inside tabpanel with switchType "client"</p>
> <h:form>
> <rich:tabPanel switchType="client">
> <rich:tab>
> <f:facet name="header">
> Tab One
> </f:facet>
> Tab One
> </rich:tab>
> <rich:tab>
> <f:facet name="header">
> Tab Two
> </f:facet>
> <rich:extendedDataTable value="#{colorsBean.colors}" var="color">
> <rich:column>
> <f:facet name="header">
> Column 1
> </f:facet>
> #{color}
> </rich:column>
> </rich:extendedDataTable>
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> </h:body>
> </html>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13552) EPVC includes <extension> twice in <partial-response> when JRebel is used
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13552?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13552:
---------------------------------
Might be just issue with 5.5.1-SNAPSHOT, let me try newest nightly (latest stable is 5.5).
> EPVC includes <extension> twice in <partial-response> when JRebel is used
> -------------------------------------------------------------------------
>
> Key: RF-13552
> URL: https://issues.jboss.org/browse/RF-13552
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.3.5, 5.0.0.Alpha4
> Environment: WildFly 8.0.0.Final
> JRebel 5.5.1-SNAPSHOT (201401071651)
> Reporter: Lukáš Fryč
>
> {code}
> <partial-response>
> <changes>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> </changes>
> </partial-response>
> {code}
> ---
> The reason is that EPVCFactory is called twice:
> * first, it gets PVCFactory as a constructor,
> * but second, it gets EPVCFactory
> So at the end, we have EPVC wrapped in EPVC which wraps PVC:
> {code}
> EPVC(EPVC(PVC))
> {code}
> The workaround is detecting this behavior in the EPVCFactory
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
> and do not wrap EPVC when context provided from parentFactory is EPVC and return that context directly.
> ---
> Additionally we should coordinate with JRebel to resolve this issue there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13552) EPVC includes <extension> twice in <partial-response> when JRebel is used
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13552?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13552:
----------------------------
Affects Version/s: 4.3.5
5.0.0.Alpha4
> EPVC includes <extension> twice in <partial-response> when JRebel is used
> -------------------------------------------------------------------------
>
> Key: RF-13552
> URL: https://issues.jboss.org/browse/RF-13552
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.3.5, 5.0.0.Alpha4
> Reporter: Lukáš Fryč
>
> {code}
> <partial-response>
> <changes>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> </changes>
> </partial-response>
> {code}
> ---
> The reason is that EPVCFactory is called twice:
> * first, it gets PVCFactory as a constructor,
> * but second, it gets EPVCFactory
> So at the end, we have EPVC wrapped in EPVC which wraps PVC:
> {code}
> EPVC(EPVC(PVC))
> {code}
> The workaround is detecting this behavior in the EPVCFactory
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
> and do not wrap EPVC when context provided from parentFactory is EPVC and return that context directly.
> ---
> Additionally we should coordinate with JRebel to resolve this issue there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13552) EPVC includes <extension> twice in <partial-response> when JRebel is used
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13552?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13552:
----------------------------
Environment:
WildFly 8.0.0.Final
JRebel 5.5.1-SNAPSHOT (201401071651)
> EPVC includes <extension> twice in <partial-response> when JRebel is used
> -------------------------------------------------------------------------
>
> Key: RF-13552
> URL: https://issues.jboss.org/browse/RF-13552
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Affects Versions: 4.3.5, 5.0.0.Alpha4
> Environment: WildFly 8.0.0.Final
> JRebel 5.5.1-SNAPSHOT (201401071651)
> Reporter: Lukáš Fryč
>
> {code}
> <partial-response>
> <changes>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> </changes>
> </partial-response>
> {code}
> ---
> The reason is that EPVCFactory is called twice:
> * first, it gets PVCFactory as a constructor,
> * but second, it gets EPVCFactory
> So at the end, we have EPVC wrapped in EPVC which wraps PVC:
> {code}
> EPVC(EPVC(PVC))
> {code}
> The workaround is detecting this behavior in the EPVCFactory
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
> and do not wrap EPVC when context provided from parentFactory is EPVC and return that context directly.
> ---
> Additionally we should coordinate with JRebel to resolve this issue there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13552) EPVC includes <extension> tag twice when JRebel is used
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13552?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13552:
----------------------------
Description:
{code}
<partial-response>
<changes>
<extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
<extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
</changes>
</partial-response>
{code}
---
The reason is that EPVCFactory is called twice:
* first, it gets PVCFactory as a constructor,
* but second, it gets EPVCFactory
So at the end, we have EPVC wrapped in EPVC which wraps PVC:
{code}
EPVC(EPVC(PVC))
{code}
The workaround is detecting this behavior in the EPVCFactory
https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
and do not wrap EPVC when context provided from parentFactory is EPVC and return that context directly.
---
Additionally we should coordinate with JRebel to resolve this issue there.
was:
The reason is that EPVCFactory is called twice:
* first, it gets PVCFactory as a constructor,
* but second, it gets EPVCFactory
So at the end, we have EPVC wrapped in EPVC which wraps PVC:
{code}
EPVC(EPVC(PVC))
{code}
The workaround is detecting this behavior in the EPVCFactory
https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
and do not wrap EPVC when context provided from parentFactory is EPVC and return that context directly.
---
Additionally we should coordinate with JRebel to resolve this issue there.
> EPVC includes <extension> tag twice when JRebel is used
> -------------------------------------------------------
>
> Key: RF-13552
> URL: https://issues.jboss.org/browse/RF-13552
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Reporter: Lukáš Fryč
>
> {code}
> <partial-response>
> <changes>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> </changes>
> </partial-response>
> {code}
> ---
> The reason is that EPVCFactory is called twice:
> * first, it gets PVCFactory as a constructor,
> * but second, it gets EPVCFactory
> So at the end, we have EPVC wrapped in EPVC which wraps PVC:
> {code}
> EPVC(EPVC(PVC))
> {code}
> The workaround is detecting this behavior in the EPVCFactory
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
> and do not wrap EPVC when context provided from parentFactory is EPVC and return that context directly.
> ---
> Additionally we should coordinate with JRebel to resolve this issue there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13552) EPVC includes <extension> twice in <partial-response> when JRebel is used
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13552?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13552:
----------------------------
Summary: EPVC includes <extension> twice in <partial-response> when JRebel is used (was: EPVC includes <extension> tag twice when JRebel is used)
> EPVC includes <extension> twice in <partial-response> when JRebel is used
> -------------------------------------------------------------------------
>
> Key: RF-13552
> URL: https://issues.jboss.org/browse/RF-13552
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component
> Reporter: Lukáš Fryč
>
> {code}
> <partial-response>
> <changes>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> <extension id="org.richfaces.extension"><complete>alert('oncomplete')</complete><render>messages</render></extension>
> </changes>
> </partial-response>
> {code}
> ---
> The reason is that EPVCFactory is called twice:
> * first, it gets PVCFactory as a constructor,
> * but second, it gets EPVCFactory
> So at the end, we have EPVC wrapped in EPVC which wraps PVC:
> {code}
> EPVC(EPVC(PVC))
> {code}
> The workaround is detecting this behavior in the EPVCFactory
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
> and do not wrap EPVC when context provided from parentFactory is EPVC and return that context directly.
> ---
> Additionally we should coordinate with JRebel to resolve this issue there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13250) Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13250?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-13250 at 2/19/14 1:46 PM:
----------------------------------------------------------
Thanks for reproducing this [~jhuska].
One thing that should be certainly done differently is using javax.faces.ProjectStage=Production.
Have you verified whether attached patch fixes the issue?
> Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
> --------------------------------------------------------------
>
> Key: RF-13250
> URL: https://issues.jboss.org/browse/RF-13250
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4, 4.3.5
> Environment: Gentoo Linux, Tomcat 7.0.39, MyFaces 2.1.12, Tomahawk 1.1.14, RichFaces 4.3.4, APR 1.4.5
> Reporter: Milo van der Zee
> Assignee: Juraj Húska
> Labels: memoryleak
> Attachments: rf.patch
>
>
> Hello,
> I did an upgrade from RF 4.3.3.Final to 4.3.4.Final and the application started to crash with 'Out Off Memory' errors. I changed the POM back to 4.3.3.Final and the problem is gone.
> I also started seeing this message lot's of times:
> {{WARN org.atmosphere.cpr.AtmosphereResponse - Committed error code 400}}
> I don't know if that has anything to do with the error. I set {{org.atmosphere.cpr.sessionSupport}} to {{true}} and I did not see the message again. But still the application went out-of-memory.
> In the crashed system heap dump I see a lot of:
> - AtomicBoolean (751.000, 15.0MB)
> - ConcurrentLinkedQueue
> - AtmospereRequest$Builder (60.042, 13.8MB)
> To me it looks like it has something to do with Atmosphere. Any ideas?
> Thanks,
> Milo van der Zee
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13250) Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13250?page=com.atlassian.jira.plugin.s... ]
Juraj Húska edited comment on RF-13250 at 2/19/14 11:58 AM:
------------------------------------------------------------
I have reproduced the issue with the description provided by community also with RichFaces 5.x version.
The reproducer can be found at [this|https://github.com/richfaces/richfaces/tree/RF-13250] branch. Test script will start an Arquillian test, which will start JBoss AS 7.1.1.Final instance with 256Mb max heap size. It will then try to simulate 4 users (not simultaneous), receiving push events. Another script is in the meantime making invalid push requests causing the heap exceeding its allowed size.
Steps to reproduce:
# checkout referenced branch
# issue:
{code}
cd examples/push-demo/
mvn clean verify -Dtest.timeout=2160000
{code}
# from another terminal window issue:
{code}
cd examples/push-demo/
bash malformedPushRequestScript.sh
{code}
# where {{-Dtest.timeout}} is timeout for running the test in milliseconds, e.g. 2160000 == 6 hours, I was able to reproduce it in 4 hours
# after e.g. 4 hours check that the test output contains {{OOM exception}}
This OOM exceptions which can be found in the server log:
{code}
16:05:28,635 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/push].[Faces Servlet]] (http--127.0.0.1-8080-3) Servlet.service() for servlet Faces Servlet threw exception: java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.Arrays.copyOfRange(Arrays.java:2694) [rt.jar:1.7.0_45]
at java.lang.String.<init>(String.java:203) [rt.jar:1.7.0_45]
at java.lang.String.substring(String.java:1913) [rt.jar:1.7.0_45]
at java.lang.String.trim(String.java:2732) [rt.jar:1.7.0_45]
at com.sun.faces.facelets.util.DevTools.writeStart(DevTools.java:419) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.facelets.util.DevTools.writeComponent(DevTools.java:245) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.facelets.util.DevTools.writeComponent(DevTools.java:264) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.facelets.util.DevTools.writeComponent(DevTools.java:264) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:128) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.renderkit.RenderKitUtils.renderHtmlErrorPage(RenderKitUtils.java:1159) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:273) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:142) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.7-jbossorg-2.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
{code}
and
{code}
6:07:41,281 WARN [org.hornetq.core.remoting.server.impl.RemotingServiceImpl] (hornetq-failure-check-thread) GC overhead limit exceeded: java.lang.OutOfMemoryError: GC overhead limit exceeded
{code}.
was (Author: jhuska):
I have reproduced the issue with the description provided by community.
The reproducer can be found at [this|https://github.com/richfaces/richfaces/tree/RF-13250] branch. Test script will start an Arquillian test, which will start JBoss AS 7.1.1.Final instance with 256Mb max heap size. It will then try to simulate 4 users (not simultaneous), receiving push events. Another script is in the meantime making invalid push requests causing the heap exceeding its allowed size.
Steps to reproduce:
# checkout referenced branch
# issue:
{code}
cd examples/push-demo/
mvn clean verify -Dtest.timeout=2160000
{code}
# from another terminal window issue:
{code}
cd examples/push-demo/
bash malformedPushRequestScript.sh
{code}
# where {{-Dtest.timeout}} is timeout for running the test in milliseconds, e.g. 2160000 == 6 hours, I was able to reproduce it in 4 hours
# after e.g. 4 hours check that the test output contains {{OOM exception}}
This OOM exceptions which can be found in the server log:
{code}
16:05:28,635 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/push].[Faces Servlet]] (http--127.0.0.1-8080-3) Servlet.service() for servlet Faces Servlet threw exception: java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.Arrays.copyOfRange(Arrays.java:2694) [rt.jar:1.7.0_45]
at java.lang.String.<init>(String.java:203) [rt.jar:1.7.0_45]
at java.lang.String.substring(String.java:1913) [rt.jar:1.7.0_45]
at java.lang.String.trim(String.java:2732) [rt.jar:1.7.0_45]
at com.sun.faces.facelets.util.DevTools.writeStart(DevTools.java:419) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.facelets.util.DevTools.writeComponent(DevTools.java:245) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.facelets.util.DevTools.writeComponent(DevTools.java:264) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.facelets.util.DevTools.writeComponent(DevTools.java:264) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.facelets.util.DevTools.debugHtml(DevTools.java:128) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.renderkit.RenderKitUtils.renderHtmlErrorPage(RenderKitUtils.java:1159) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.context.ExceptionHandlerImpl.throwIt(ExceptionHandlerImpl.java:273) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:142) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.7-jbossorg-2.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
{code}
and
{code}
6:07:41,281 WARN [org.hornetq.core.remoting.server.impl.RemotingServiceImpl] (hornetq-failure-check-thread) GC overhead limit exceeded: java.lang.OutOfMemoryError: GC overhead limit exceeded
{code}.
> Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
> --------------------------------------------------------------
>
> Key: RF-13250
> URL: https://issues.jboss.org/browse/RF-13250
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4, 4.3.5
> Environment: Gentoo Linux, Tomcat 7.0.39, MyFaces 2.1.12, Tomahawk 1.1.14, RichFaces 4.3.4, APR 1.4.5
> Reporter: Milo van der Zee
> Assignee: Juraj Húska
> Labels: memoryleak
> Attachments: rf.patch
>
>
> Hello,
> I did an upgrade from RF 4.3.3.Final to 4.3.4.Final and the application started to crash with 'Out Off Memory' errors. I changed the POM back to 4.3.3.Final and the problem is gone.
> I also started seeing this message lot's of times:
> {{WARN org.atmosphere.cpr.AtmosphereResponse - Committed error code 400}}
> I don't know if that has anything to do with the error. I set {{org.atmosphere.cpr.sessionSupport}} to {{true}} and I did not see the message again. But still the application went out-of-memory.
> In the crashed system heap dump I see a lot of:
> - AtomicBoolean (751.000, 15.0MB)
> - ConcurrentLinkedQueue
> - AtmospereRequest$Builder (60.042, 13.8MB)
> To me it looks like it has something to do with Atmosphere. Any ideas?
> Thanks,
> Milo van der Zee
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (RF-13250) Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13250?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-13250:
----------------------------------
[~lfryc] could you please check my testing approach and suggest improvements ? What else/differently can be tested ?
> Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
> --------------------------------------------------------------
>
> Key: RF-13250
> URL: https://issues.jboss.org/browse/RF-13250
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4, 4.3.5
> Environment: Gentoo Linux, Tomcat 7.0.39, MyFaces 2.1.12, Tomahawk 1.1.14, RichFaces 4.3.4, APR 1.4.5
> Reporter: Milo van der Zee
> Assignee: Juraj Húska
> Labels: memoryleak
> Attachments: rf.patch
>
>
> Hello,
> I did an upgrade from RF 4.3.3.Final to 4.3.4.Final and the application started to crash with 'Out Off Memory' errors. I changed the POM back to 4.3.3.Final and the problem is gone.
> I also started seeing this message lot's of times:
> {{WARN org.atmosphere.cpr.AtmosphereResponse - Committed error code 400}}
> I don't know if that has anything to do with the error. I set {{org.atmosphere.cpr.sessionSupport}} to {{true}} and I did not see the message again. But still the application went out-of-memory.
> In the crashed system heap dump I see a lot of:
> - AtomicBoolean (751.000, 15.0MB)
> - ConcurrentLinkedQueue
> - AtmospereRequest$Builder (60.042, 13.8MB)
> To me it looks like it has something to do with Atmosphere. Any ideas?
> Thanks,
> Milo van der Zee
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months