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]
