great. so... to make sure where are all of the places that caching could be disabled? I only know of the system property option.
Howard Lewis Ship wrote: > I'm very familiar with the code in question; it uses the exact same > code path as any other page access and is no more likely to leak than > any other page access .. .unless you are running with caching > disabled. Check that first. > > > > On 9/18/05, Fernando Padilla <[EMAIL PROTECTED]> wrote: > >>So.. >> >>Has anyone put Tapestry 4-beta4 on a profiler, and maybe repeatedly hit >>a url that would throw a PageRedirectException on pageValidate??? >> >>Well, I have. And yes, there is a memory leak. And this ain't good for >>production systems. >> >> >>I am really tired so tomorrow I can give out more details, but i wanted >>to send out this email to see if anyone already knew what was going wrong. >> >> >> >>I haven't taken the time to read the code, but it seems that when >>pageValidate fails, it causes tapestry to always rebuild the page >>template of the next page ( like the LoginPage ). While rebuilding the >>page template it does a lot of reflection, as well as Binding object >>creation and somehow that is what is leaked. >> >>On one test ( RedHat ), I was getting a leak of >>sun.reflect.GeneratedMethodAccessor* objects, and a goole search only >>came up with this: http://www.burnthacker.com/archives/000160.html So I >>thought it might be a simple configuration change. >> >>But then today I ran a test on a different box ( Gentoo ), and I was >>getting leaks of the org.apache.tapestry.binding.ExpressionBinding and >>LiteralBinding objects. >> >> >> >>So, no matter what is wrong with the VM's reflection classgc settings, >>Tapestry shouldn't be rebuilding the page template on every request that >>fails pageValidate. Conceptually it makes since, if a page in not valid >>it shouldn't return to the pool, but if that is so then we should not be >>using it for authorization/authentication checking.. >> >> >> >>any help? I'll probably start looking through the pageValidate code >>tomorrow to see if I can track this down.. but I really hope someone >>else more experience with this code can suggest ideas right away. >> >>The second option i have is to not use the pageValidate method at all, >>and instead do a ServletFilter to manage authorization management.. >> >> >>Fernando >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
