Re: Memory leak?
Thanks, I think I found it in:
FacesContextImpl.release():
_facesContextFactory = null;
_renderKitFactory = null;
_partialViewContextFactory = null;
if (_facesContextFactory != null)
{
_facesContextFactory.release();
_facesContextFactory = null;
}
(_facesContextFactory is set to null and then tested for null).
I filed a bug report at https://issues.apache.org/jira/browse/MYFACES-3585.
Regards,
Pavel
2012/7/13 Rohit Kelapure :
> The way to fix this is to find out what MyFaces code is putting the
> ServletExternalContextImpl on the Threadlocal and
> not cleaning it up after the request ends.
>
> -cheers,
> ROhit
>
> On Thu, Jul 12, 2012 at 3:26 PM, Pavel Arnošt wrote:
>> Hi,
>>
>> I have very simple setup of Tomcat 7.0.29 and MyFaces 2.1.8 and when I
>> reload application, I see:
>>
>> VII 12, 2012 9:21:49 ODP. org.apache.catalina.loader.WebappClassLoader
>> checkThreadLocalMapForLeaks
>> SEVERE: The web application [/evidence] created a ThreadLocal with key
>> of type [java.lang.ThreadLocal] (value
>> [java.lang.ThreadLocal@1529c06]) and a value of type
>> [org.apache.myfaces.context.servlet.ServletExternalContextImpl] (value
>> [org.apache.myfaces.context.servlet.ServletExternalContextImpl@fd6c78])
>> but failed to remove it when the web application was stopped. Threads
>> are going to be renewed over time to try and avoid a probable memory
>> leak.
>>
>> Message is repeated several times. The more I use the JSF application,
>> the more messages I see.
>>
>> Is there a way how can I fix it?
>>
>> Thanks,
>> Regards
>> Pavel
Re: Memory leak?
Hi, I did, but I didn't find anything about ThreadLocal and ServletExternalContextImpl. Tomcat's memory leak protection is described at http://wiki.apache.org/tomcat/MemoryLeakProtection and code is at http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java (method checkThreadLocalMapForLeaks), but it's quite advanced stuff for me. 2012/7/12 Milo van der Zee : > Hello, > > I always have the same and I can't say I see any memory leak anymore. > Even after weeks of intensive running the memory does not increase. > > I vaguely remember that it is no issue. Did you search StackExchange? > > MAG, > Milo > > > On Thu, 2012-07-12 at 21:26 +0200, Pavel Arnošt wrote: >> Hi, >> >> I have very simple setup of Tomcat 7.0.29 and MyFaces 2.1.8 and when I >> reload application, I see: >> >> VII 12, 2012 9:21:49 ODP. org.apache.catalina.loader.WebappClassLoader >> checkThreadLocalMapForLeaks >> SEVERE: The web application [/evidence] created a ThreadLocal with key >> of type [java.lang.ThreadLocal] (value >> [java.lang.ThreadLocal@1529c06]) and a value of type >> [org.apache.myfaces.context.servlet.ServletExternalContextImpl] (value >> [org.apache.myfaces.context.servlet.ServletExternalContextImpl@fd6c78]) >> but failed to remove it when the web application was stopped. Threads >> are going to be renewed over time to try and avoid a probable memory >> leak. >> >> Message is repeated several times. The more I use the JSF application, >> the more messages I see. >> >> Is there a way how can I fix it? >> >> Thanks, >> Regards >> Pavel > >
Memory leak?
Hi, I have very simple setup of Tomcat 7.0.29 and MyFaces 2.1.8 and when I reload application, I see: VII 12, 2012 9:21:49 ODP. org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: The web application [/evidence] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1529c06]) and a value of type [org.apache.myfaces.context.servlet.ServletExternalContextImpl] (value [org.apache.myfaces.context.servlet.ServletExternalContextImpl@fd6c78]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Message is repeated several times. The more I use the JSF application, the more messages I see. Is there a way how can I fix it? Thanks, Regards Pavel
Message order in h:messages does not match component order
Hi, with template: messages in h:messages does not match order of components, h:messages will show: 2: Validation error 3: Validation error 1: Validation error It looks like that problem occurs where h:messages is wrapped in another component, this works: but this doesn't: With Mojarra h:messages or PrimeFaces p:messages message order does match component order. Should I file this as bug? Regards, Pavel
Re[4]: "No saved view state could be found" after redeploy
Thanks. It should be probably mentioned at "Configuring MyFaces" and "FAQ". Section with best practices and recommendations at "Secure Your Application" would also be great, it's not that obvious what algorithms and key sizes are best for production. -- Původní zpráva -- Od: "Leonardo Uribe" Komu: "MyFaces Discussion" ;"Pavel Arnošt" Odesláno: 21.6.2012 7:33:29 Předmět: Re: Re[2]: "No saved view state could be found" after redeploy Hi It is a known situation. You need to check the instructions here: http://wiki.apache.org/myfaces/Secure_Your_Application When you redeploy your app, a new encryption key is generated, so the old view state cannot be decoded and ViewExpiredException is thrown. Just set the right params and that's it. regards, Leonardo Uribe 2012/6/21 Pavel Arnošt : Hi Ted, 1) tomcat session persistence should be on by default and "" is commented out, so I suppose that it's on 2) state saving metod should be server, it's default and javax.faces.STATE_SAVING_METHOD in web.xml is set to server With Tomcat 7.0.27+OWB 1.1.4+MyFaces 2.1.8+CODI 1.0.5 exception is thrown, with Tomcat 7.0.27+OWB 1.1.4+Mojarra 2.1.9+CODI 1.0.5 it is not. I have not found anything unsual in Tomcat's log. I tried it once more now, with javax.faces.STATE_SAVING_METHOD set to client in web.xml, and it also throws ViewExpiredException, strange. -- Původní zpráva -- Od: "Ted" Komu: "MyFaces Discussion" ;"Pavel Arnošt" Odesláno: 20.6.2012 23:58:12 Předmět: Re: "No saved view state could be found" after redeploy there's 2 things you might want to check 1) tomcat's session persistance across tomcat restarts : http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html 2) jsf state saving method, i.e. client or server On Thu, Jun 21, 2012 at 7:16 AM, Pavel Arnošt wrote: Hi, I have simple page with one form. When I: 1) load page 2) redeploy application 3) submit form exception is thrown: /index.facesNo saved view state could be found for the view identifier: /index.faces Caused by: javax.faces.application.ViewExpiredException - /index.facesNo saved view state could be found for the view identifier: /index.faces at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:132) Server is Tomcat 7.0.27 with OWB 1.1.4, MyFaces 2.1.8 and CODI 1.0.5. I have tried replacing MyFaces with Mojarra 2.1.9 and no exception is thrown with Mojarra in submit after redeploy. Why MyFaces throws exception and Mojarra don't? Thanks, Regards, Pavel -- Ted.
Re[2]: "No saved view state could be found" after redeploy
Hi Ted, 1) tomcat session persistence should be on by default and "" is commented out, so I suppose that it's on 2) state saving metod should be server, it's default and javax.faces.STATE_SAVING_METHOD in web.xml is set to server With Tomcat 7.0.27+OWB 1.1.4+MyFaces 2.1.8+CODI 1.0.5 exception is thrown, with Tomcat 7.0.27+OWB 1.1.4+Mojarra 2.1.9+CODI 1.0.5 it is not. I have not found anything unsual in Tomcat's log. I tried it once more now, with javax.faces.STATE_SAVING_METHOD set to client in web.xml, and it also throws ViewExpiredException, strange. -- Původní zpráva -- Od: "Ted" Komu: "MyFaces Discussion" ;"Pavel Arnošt" Odesláno: 20.6.2012 23:58:12 Předmět: Re: "No saved view state could be found" after redeploy there's 2 things you might want to check 1) tomcat's session persistance across tomcat restarts : http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html 2) jsf state saving method, i.e. client or server On Thu, Jun 21, 2012 at 7:16 AM, Pavel Arnošt wrote: Hi, I have simple page with one form. When I: 1) load page 2) redeploy application 3) submit form exception is thrown: /index.facesNo saved view state could be found for the view identifier: /index.faces Caused by: javax.faces.application.ViewExpiredException - /index.facesNo saved view state could be found for the view identifier: /index.faces at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:132) Server is Tomcat 7.0.27 with OWB 1.1.4, MyFaces 2.1.8 and CODI 1.0.5. I have tried replacing MyFaces with Mojarra 2.1.9 and no exception is thrown with Mojarra in submit after redeploy. Why MyFaces throws exception and Mojarra don't? Thanks, Regards, Pavel -- Ted.
"No saved view state could be found" after redeploy
Hi, I have simple page with one form. When I: 1) load page 2) redeploy application 3) submit form exception is thrown: /index.facesNo saved view state could be found for the view identifier: /index.faces Caused by: javax.faces.application.ViewExpiredException - /index.facesNo saved view state could be found for the view identifier: /index.faces at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:132) Server is Tomcat 7.0.27 with OWB 1.1.4, MyFaces 2.1.8 and CODI 1.0.5. I have tried replacing MyFaces with Mojarra 2.1.9 and no exception is thrown with Mojarra in submit after redeploy. Why MyFaces throws exception and Mojarra don't? Thanks, Regards, Pavel
Re[2]: [CODI] ViewAccessScoped beans without windowId in URL
Hi all, first, I apologize for double post, it looks like that Nabble gateway does not work very well, it nagged me with "could not deliver" messages and even now your messages are not available at Nabble (http://old.nabble.com/MyFaces---Users-f181.html). Thanks for all your replies. WindowContextConfig#isUrlParameterSupported is really sufficient for working ViewAccessScope without windowId in URL, I confused "creates new beans" with "invokes @PostConstruct at every request". And thats expected, as discussed at http://stackoverflow.com/questions/2797231/why-does-postconstruct-callback-fire-every-time-even-though-bean-is-viewscoped. I believe that windowId functionality is great, but on simple public pages such as "Give us feedback" or "Register with us", windowId parameter is a little ugly, losing of context with reload is not a problem here and ViewAccessScope is very handy for AJAX feedback. Regards, Pavel -- Původní zpráva -- Od: "Mark Struberg" Komu: "MyFaces Discussion" Odesláno: 10.5.2012 16:03:08 Předmět: Re: [CODI] ViewAccessScoped beans without windowId in URL Hi folks! We've done some intense testing and I really suggest to use the windowId url parameter and also to use the ClientSideWindowhandler with the windowhandler.js and windowhandler.html stuff. If you have customers/users which are used to open multiple browser tabs, then this is the only perfectly working solution. Btw, the windowId in the URL doesn't make any problem because it will get checked against the window.name. And if those doesn't fit then we just request a new windowId. LieGrue, strub - Original Message - From: Rafael Pestano To: MyFaces Discussion ; Pavel Arnošt Cc: Sent: Thursday, May 10, 2012 3:20 PM Subject: Re: [CODI] ViewAccessScoped beans without windowId in URL Hi Pavel, WindowContextConfig#isUrlParameterSupported should be enough, does serverside demo work for you? http://people.apache.org/~gpetracek/myfaces/codi/demos/serverside_demo_jsf12.zip keep in mind that the bean will not survive to a redirect. I hope it helps. Att, Rafael M. Pestano Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul Graduando em Ciência da Computação UFRGS http://code.google.com/p/jsf-conventions-framework/ http://rpestano.wordpress.com @realpestano De: Pavel Arnošt Para: users@myfaces.apache.org Enviadas: Quinta-feira, 10 de Maio de 2012 9:41 Assunto: [CODI] ViewAccessScoped beans without windowId in URL Hi, I already read documentation in the wiki and several old posts, but I don't still get it - is it possible to use ViewAccessScoped beans without windowId in URL? When I disable WindowContextConfig#isUrlParameterSupported, windowId is gone but AJAX calls now creates new bean instances on requests. In javadoc, there is a note about "server-side window-handler", how can I use it? Thanks, Regards, Pavel Arnost
[CODI] ViewAccessScoped beans without windowId in URL
Hi, I already read documentation in the wiki and several old posts, but I don't still get it - is it possible to use ViewAccessScoped beans without windowId in URL? When I disable WindowContextConfig#isUrlParameterSupported, windowId is gone but AJAX calls now creates new bean instances on requests. In javadoc, there is a note about "server-side window-handler", how can I use it? Thanks, Regards, Pavel Arnost
