[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13071?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13071:
-------------------------------
Fix Version/s: 5-Tracking
> Undeploying Showcase from Tomcat6/7 can cause memory leak
> ---------------------------------------------------------
>
> Key: RF-13071
> URL: https://issues.jboss.org/browse/RF-13071
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll, showcase
> Affects Versions: 4.1.0.Final, 5.0.0.Alpha1
> Reporter: Juraj Húska
> Priority: Minor
> Fix For: 5-Tracking
>
>
> When undeploying showcase from Tomcat 6/7 then following log is present on the server console:
> {code}
> SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak.
> {code}
> There is lot of such logs, just the _Thread-counter_ is changing.
> * 11 such logs just with showcase deploying and then right after undeploying
> * bit more when after deploying playing a little bit with {{r:push}}
> IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}}
--
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
11 years, 5 months
[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13071?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13071:
-------------------------------
Labels: memory_leak performance (was: )
> Undeploying Showcase from Tomcat6/7 can cause memory leak
> ---------------------------------------------------------
>
> Key: RF-13071
> URL: https://issues.jboss.org/browse/RF-13071
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll, showcase
> Affects Versions: 4.1.0.Final, 5.0.0.Alpha1
> Reporter: Juraj Húska
> Priority: Minor
> Labels: memory_leak, performance
> Fix For: 5-Tracking
>
>
> When undeploying showcase from Tomcat 6/7 then following log is present on the server console:
> {code}
> SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak.
> {code}
> There is lot of such logs, just the _Thread-counter_ is changing.
> * 11 such logs just with showcase deploying and then right after undeploying
> * bit more when after deploying playing a little bit with {{r:push}}
> IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}}
--
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
11 years, 5 months
[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13071?page=com.atlassian.jira.plugin.s... ]
Juraj Húska edited comment on RF-13071 at 6/20/13 6:13 AM:
-----------------------------------------------------------
The issue is occurring for previous versions of RichFaces as well. I am not sure whether the increased demand for memory was not caused by bigger Showcase {{.war}} rather than the memory leak. It needs more investigation. Tell me If I should deep in it more.
was (Author: jhuska):
The issue is occurring for previous versions of RichFaces as well.
> Undeploying Showcase from Tomcat6/7 can cause memory leak
> ---------------------------------------------------------
>
> Key: RF-13071
> URL: https://issues.jboss.org/browse/RF-13071
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll, showcase
> Affects Versions: 4.1.0.Final, 5.0.0.Alpha1
> Reporter: Juraj Húska
> Priority: Minor
>
> When undeploying showcase from Tomcat 6/7 then following log is present on the server console:
> {code}
> SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak.
> {code}
> There is lot of such logs, just the _Thread-counter_ is changing.
> * 11 such logs just with showcase deploying and then right after undeploying
> * bit more when after deploying playing a little bit with {{r:push}}
> IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}}
--
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
11 years, 5 months
[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13071?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-13071:
----------------------------------
The issue is occurring for previous versions of RichFaces as well.
> Undeploying Showcase from Tomcat6/7 can cause memory leak
> ---------------------------------------------------------
>
> Key: RF-13071
> URL: https://issues.jboss.org/browse/RF-13071
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll, showcase
> Affects Versions: 5.0.0.Alpha1
> Reporter: Juraj Húska
> Priority: Minor
>
> When undeploying showcase from Tomcat 6/7 then following log is present on the server console:
> {code}
> SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak.
> {code}
> There is lot of such logs, just the _Thread-counter_ is changing.
> * 11 such logs just with showcase deploying and then right after undeploying
> * bit more when after deploying playing a little bit with {{r:push}}
> IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}}
--
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
11 years, 5 months
[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13071?page=com.atlassian.jira.plugin.s... ]
Juraj Húska updated RF-13071:
-----------------------------
Affects Version/s: 4.1.0.Final
> Undeploying Showcase from Tomcat6/7 can cause memory leak
> ---------------------------------------------------------
>
> Key: RF-13071
> URL: https://issues.jboss.org/browse/RF-13071
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll, showcase
> Affects Versions: 4.1.0.Final, 5.0.0.Alpha1
> Reporter: Juraj Húska
> Priority: Minor
>
> When undeploying showcase from Tomcat 6/7 then following log is present on the server console:
> {code}
> SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak.
> {code}
> There is lot of such logs, just the _Thread-counter_ is changing.
> * 11 such logs just with showcase deploying and then right after undeploying
> * bit more when after deploying playing a little bit with {{r:push}}
> IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}}
--
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
11 years, 5 months
[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13071?page=com.atlassian.jira.plugin.s... ]
Juraj Húska updated RF-13071:
-----------------------------
Priority: Minor (was: Major)
> Undeploying Showcase from Tomcat6/7 can cause memory leak
> ---------------------------------------------------------
>
> Key: RF-13071
> URL: https://issues.jboss.org/browse/RF-13071
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll, showcase
> Affects Versions: 5.0.0.Alpha1
> Reporter: Juraj Húska
> Priority: Minor
>
> When undeploying showcase from Tomcat 6/7 then following log is present on the server console:
> {code}
> SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak.
> {code}
> There is lot of such logs, just the _Thread-counter_ is changing.
> * 11 such logs just with showcase deploying and then right after undeploying
> * bit more when after deploying playing a little bit with {{r:push}}
> IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}}
--
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
11 years, 5 months
[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak
by Juraj Húska (JIRA)
Juraj Húska created RF-13071:
--------------------------------
Summary: Undeploying Showcase from Tomcat6/7 can cause memory leak
Key: RF-13071
URL: https://issues.jboss.org/browse/RF-13071
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: component-push/poll, showcase
Affects Versions: 5.0.0.Alpha1
Reporter: Juraj Húska
When undeploying showcase from Tomcat 6/7 then following log is present on the server console:
{code}
SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak.
{code}
There is lot of such logs, just the _Thread-counter_ is changing.
* 11 such logs just with showcase deploying and then right after undeploying
* bit more when after deploying playing a little bit with {{r:push}}
IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}}
--
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
11 years, 5 months
[JBoss JIRA] (RF-13061) r:fileUpload stops working: "Request prolog cannot be read"
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/RF-13061?page=com.atlassian.jira.plugin.s... ]
Juergen Zimmermann commented on RF-13061:
-----------------------------------------
Sounds good to me. As soon as RF 5.0.0.Alpha2 is available I'll come back and will test it with WildFly and JSF2.2.
> r:fileUpload stops working: "Request prolog cannot be read"
> -----------------------------------------------------------
>
> Key: RF-13061
> URL: https://issues.jboss.org/browse/RF-13061
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 5.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> I just tried r:fileUpload with the current snapshot for WildFly 8.0.0.Alpha2 (changed Mojarra 2.2.0 to 2.1.23). It actually looks pretty good. However, I'm getting this stacktrace for fileUpload:
> {code}
> 16:33:44,571 SEVERE [org.richfaces.log.Application] Exception parsing multipart request: Request prolog cannot be read: org.richfaces.ui.input.fileUpload.FileUploadException: Exception parsing multipart request: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:156) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequest25.parseIfNecessary(MultipartRequest25.java:77) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequest25.getParameter(MultipartRequest25.java:114) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:75) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.RequestParameterMap.get(RequestParameterMap.java:56) [jsf-impl-2.1.23.jar:2.1.23]
> at java.util.Collections$UnmodifiableMap.get(Collections.java:1339) [rt.jar:1.7.0_21]
> at com.sun.faces.facelets.tag.ui.UIDebug.debugRequest(UIDebug.java:168) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash$PreviousNextFlashInfoManager.decode(ELFlash.java:1225) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash.getCurrentFlashManager(ELFlash.java:1059) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.context.flash.ELFlash.doPrePhaseActions(ELFlash.java:557) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:215) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) [jsf-impl-2.1.23.jar:2.1.23]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.23.jar:2.1.23]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.23.jar:2.1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:138) [undertow-websockets-jsr-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:115) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:127) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.io.IOException: Request prolog cannot be read
> at org.richfaces.request.MultipartRequestParser.readProlog(MultipartRequestParser.java:270) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequestParser.initialize(MultipartRequestParser.java:172) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> at org.richfaces.request.MultipartRequestParser.parse(MultipartRequestParser.java:148) [richfaces-5.0.0.Alpha1.jar:5.0.0.Alpha1]
> ... 43 more
> {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
11 years, 5 months