But remember that, if you are stress testing Tapestry, you'll be in situations where Tapestry has to create multiple instances of the same page. Reading the XML spec occurs once, creating the enhanced class occurs once, parsing the template occurs once, but assembling it all together may occur many times.
On 9/19/05, Fernando Padilla <[EMAIL PROTECTED]> wrote: > Alright. I need a sanity check. Could someone please double check my > beliefs: Are the following true or false. > > > 1) Caching is disabled by setting the approriate system property. And > only through that means. > > > 2) Deprecated component warnings are printed out only when a page > template is reconstructed, not on every page render. > > > > > 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] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
