[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:
----------------------------------
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, 3 months
[JBoss JIRA] (RF-13548) Clean using of guava dependency across framework
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13548?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-13548:
----------------------------------
Showcase and Metamer can not be deployed to Tomcat 8, that is what I have noticed.
I can not find the root cause of the problem, since there is no meaningful error logged to Tomcat log files (_catalina.out_, _localhost.log_) - I have also tried to increase logging level in apache-tomcat-8.0.3/conf/logging.properties. But still there is only:
{code}
19-Feb-2014 10:19:00.168 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Error listenerStart
19-Feb-2014 10:19:00.177 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.startInternal Context [/richfaces-showcase-tomcat6] startup failed due to previous errors
{code}
Which says basically nothing.
The behavior is slightly different (have no clue why) when I am trying to deploy showcase via Arquillian test to Tomcat 8. Error described in [this|https://community.jboss.org/thread/236951] thread is thrown.
You said that it is related to guava, but IMHO it is related to something else because:
* Tomcat 8 does not bundle guava.jar and does not contain classes from that library. I have used:
{code}
find -name "*.java" -exec grep "import com.google.common" {} \; | sort | uniq -c
find -name "*.java" -exec grep "ListeningExecutorService" {} \; | sort | uniq -c
{code}
over Tomcat 8 sources with no results.
* I have tried to deploy showcase with various guava libraries bundled (16, 15, 13), but still the same error.
Should I file another issue specifically for Showcase deployment ?
> Clean using of guava dependency across framework
> ------------------------------------------------
>
> Key: RF-13548
> URL: https://issues.jboss.org/browse/RF-13548
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: compatibility, core, third-party
> Affects Versions: 5.0.0.Alpha3
> Environment: Guava dependency and Tomcat 8
> Reporter: Juraj Húska
> Assignee: Lukáš Fryč
>
> As per [this|https://community.jboss.org/message/857397?et=watches.email.thread#8...] discussion we should do something with _Guava_ dependency.
> * We should investigate whether _maven shade_ plugin will be for any good
> * Investigate on refactoring the code so it does not contain dependencies from Guava marked as {{@Beta}}
> It seems that this blocks using of Tomcat 8 properly.
--
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, 3 months
[JBoss JIRA] (RF-13101) rich:select Method getSelectInputLabel is not working when using objects
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13101?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13101:
---------------------------------
So the problem is that methods are cloned and should be cleaner, but they aren't as their #equals method implementation does not consider them equal, am I right?
I think your current approach - use of converter - is a correct one.
> rich:select Method getSelectInputLabel is not working when using objects
> ------------------------------------------------------------------------
>
> Key: RF-13101
> URL: https://issues.jboss.org/browse/RF-13101
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input, component-selects
> Affects Versions: 4.3.2, 5.0.0.Alpha1
> Reporter: J W
> Labels: rich:select, select, waiting_on_user
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> The condition of the if-statement in org.richfaces.renderkit.SelectHelper.getSelectInputLabel(FacesContext facesContext, UIComponent component) is not working with the string-representations of the items. If using cloned objects the equals method will return false, even if the items are the same, because the IDs are different.
> The method should use only the strings of the objects, similiar to how MyFaces has solved this (check workarround).
--
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, 3 months
[JBoss JIRA] (RF-13538) Closeables.closeQuietly() removed in Guava 16.0, but still used in RF
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13538?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč resolved RF-13538.
-----------------------------
Assignee: Lukáš Fryč
Fix Version/s: (was: 5.0.0.Alpha4)
Resolution: Duplicate Issue
> Closeables.closeQuietly() removed in Guava 16.0, but still used in RF
> ---------------------------------------------------------------------
>
> Key: RF-13538
> URL: https://issues.jboss.org/browse/RF-13538
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
> Assignee: Lukáš Fryč
>
> For instance in org.richfaces.resource.Java2DUserResourceWrapperImpl at line 73 is an invocation of Closeables.closeQuietly(...). However, this method is removed in Guava 16.0 which is now used in RF 5.0.0.Alpha3.
> javadoc of Guava 14.0 already mentioned:
> "Deprecated. Where possible, use the try-with-resources statement if using JDK7 or Closer on JDK6 to close one or more Closeable objects. This method is deprecated because it is easy to misuse and may swallow IO exceptions that really should be thrown and handled. See Guava issue 1118 for a more detailed explanation of the reasons for deprecation and see Closing Resources for more information on the problems with closing Closeable objects and some of the preferred solutions for handling it correctly. This method is scheduled to be removed in Guava 16.0."
> Well, now the method is removed, but still invoked in RF 5.0.0.Alpha3.
--
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, 3 months
[JBoss JIRA] (RF-13247) Upgrade the Guava dependency to the 16.0.1
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13247?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-13247:
---------------------------------
The pull request that removes all @Beta APIs was merged:
https://github.com/richfaces/richfaces/pull/80
> Upgrade the Guava dependency to the 16.0.1
> ------------------------------------------
>
> Key: RF-13247
> URL: https://issues.jboss.org/browse/RF-13247
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: third-party
> Reporter: Jeremy Landis
> Assignee: Cody Lerum
> Priority: Minor
> Fix For: 5.0.0.Alpha4
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Upgrading to guava 15 from 14.0.1 causes this richfaces error. I have not looked into this further but wanted to put it out there as an issue.
> Caused by: java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.richfaces.resource.ResourceLibraryFactoryImpl
--
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, 3 months
[JBoss JIRA] (RF-13247) Upgrade the Guava dependency to the 16.0.1
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13247?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-13247:
----------------------------
Summary: Upgrade the Guava dependency to the 16.0.1 (was: Upgrade the RichFaces guava dependency to the latest version)
> Upgrade the Guava dependency to the 16.0.1
> ------------------------------------------
>
> Key: RF-13247
> URL: https://issues.jboss.org/browse/RF-13247
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: third-party
> Reporter: Jeremy Landis
> Assignee: Brian Leathem
> Priority: Minor
> Fix For: 5.0.0.Alpha4
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Upgrading to guava 15 from 14.0.1 causes this richfaces error. I have not looked into this further but wanted to put it out there as an issue.
> Caused by: java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.richfaces.resource.ResourceLibraryFactoryImpl
--
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, 3 months
[JBoss JIRA] (RF-13551) kitchensink-rf quickstart - WFK version does not match RichFaces version
by Sande Gilda (JIRA)
[ https://issues.jboss.org/browse/RF-13551?page=com.atlassian.jira.plugin.s... ]
Sande Gilda updated RF-13551:
-----------------------------
Attachment: kitchensink-rf-wfkproject.png
kitchensink-rf-richfacesproject.png
Scrrenshots of correct richfaces project version and incorrect wfk project version.
> kitchensink-rf quickstart - WFK version does not match RichFaces version
> ------------------------------------------------------------------------
>
> Key: RF-13551
> URL: https://issues.jboss.org/browse/RF-13551
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: examples
> Reporter: Sande Gilda
> Attachments: kitchensink-rf-richfacesproject.png, kitchensink-rf-wfkproject.png
>
>
> The 'kitchensink-rf' quickstart application runtime page is out of sync between the RichFaces and WFK versions.
> There is an extra section in the WFK version that should be removed:
> Learn more about JBoss EAP 6.
> Getting Started Developing Applications Guide
> Community Project Information
> The version in the RichFaces project is correct.
--
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, 3 months
[JBoss JIRA] (RF-13551) kitchensink-rf quickstart - WFK version does not match RichFaces version
by Sande Gilda (JIRA)
Sande Gilda created RF-13551:
--------------------------------
Summary: kitchensink-rf quickstart - WFK version does not match RichFaces version
Key: RF-13551
URL: https://issues.jboss.org/browse/RF-13551
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: examples
Reporter: Sande Gilda
The 'kitchensink-rf' quickstart application runtime page is out of sync between the RichFaces and WFK versions.
There is an extra section in the WFK version that should be removed:
Learn more about JBoss EAP 6.
Getting Started Developing Applications Guide
Community Project Information
The version in the RichFaces project is correct.
--
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, 3 months