Re: [T4.1] OGNL performance problem (serialization)
Aaron, I was able to reproduce your fast/slow problem using every Tap version from 4.1.1 up to 4.1.6 (and relevent ognl versions) but only when org.apache.tapestry.disable-caching was set to TRUE Perhaps you forgot to set this property back to false ? On Fri, Jan 16, 2009 at 7:46 PM, Aaron Kaminsky aar...@adaptiveplanning.com wrote: I found tapestry-prop-1.0.0 at http://howardlewisship.com/tapestry-javaforge/tapestry-prop/. I cannot seem to get it to work in 4.1.3 or 4.1.6. In both cases when I use it on a simple expression I get the exception below. I assumed that this was expected and that tapestry-prop was not supposed to work in 4.1.3+. Did I just do something wrong, and can I get it to work somehow? I would really prefer this if I can get it working. The alternative seems to be to re-structure my entire application to put ALL potentially slow computation in pageBeginRender, resulting in all ognl expressions being simple getters/setters. That would be a lot of work and I think it would not be a very clean solution. Does anyone have another approach? -- exception follows -- javassist.NotFoundException Stack Trace: javassist.ClassPool.get(ClassPool.java:436) org.apache.tapestry.enhance.CtClassSource.getCtClass(CtClassSource.java:50) org.apache.tapestry.enhance.AbstractFab.convertClass(AbstractFab.java:82) org.apache.tapestry.enhance.ClassFabImpl.addField(ClassFabImpl.java:238) com.javaforge.tapestry.prop.PropertyAccessorClassFactoryImpl.constructClass(PropertyAccessorClassFactoryImpl.java:74) $PropertyAccessorClassFactory_11ee0816124.constructClass($PropertyAccessorClassFactory_11ee0816124.java) $PropertyAccessorClassFactory_11ee0816123.constructClass($PropertyAccessorClassFactory_11ee0816123.java) com.javaforge.tapestry.prop.PropertyAccessorSourceImpl.createNewAccessorClass(PropertyAccessorSourceImpl.java:139) com.javaforge.tapestry.prop.PropertyAccessorSourceImpl.getCachedPropertyAccessorClass(PropertyAccessorSourceImpl.java:87) com.javaforge.tapestry.prop.PropertyAccessorSourceImpl.getAccessor(PropertyAccessorSourceImpl.java:55) $PropertyAccessorSource_11ee0816122.getAccessor($PropertyAccessorSource_11ee0816122.java) $PropertyAccessorSource_11ee0816121.getAccessor($PropertyAccessorSource_11ee0816121.java) com.javaforge.tapestry.prop.PropertyAccessorBindingFactory.createBinding(PropertyAccessorBindingFactory.java:36) $BindingFactory_11ee08160db.createBinding($BindingFactory_11ee08160db.java) $BindingFactory_11ee08160da.createBinding($BindingFactory_11ee08160da.java) org.apache.tapestry.services.impl.BindingSourceImpl.createBinding(BindingSourceImpl.java:99) $BindingSource_11ee0815f8d.createBinding($BindingSource_11ee0815f8d.java) org.apache.tapestry.services.impl.ComponentTemplateLoaderLogic.addTemplateBindings(ComponentTemplateLoaderLogic.java:277) org.apache.tapestry.services.impl.ComponentTemplateLoaderLogic.process(ComponentTemplateLoaderLogic.java:182) org.apache.tapestry.services.impl.ComponentTemplateLoaderLogic.process(ComponentTemplateLoaderLogic.java:98) org.apache.tapestry.services.impl.ComponentTemplateLoaderLogic.loadTemplate(ComponentTemplateLoaderLogic.java:75) org.apache.tapestry.services.impl.ComponentTemplateLoaderImpl.loadTemplate(ComponentTemplateLoaderImpl.java:60) $ComponentTemplateLoader_11ee0816051.loadTemplate($ComponentTemplateLoader_11ee0816051.java) org.apache.tapestry.pageload.PageLoader.loadTemplateForComponent(PageLoader.java:673) org.apache.tapestry.BaseComponent.readTemplate(BaseComponent.java:92) org.apache.tapestry.BaseComponent.finishLoad(BaseComponent.java:122) $Announcement_14.finishLoad($Announcement_14.java) org.apache.tapestry.pageload.PageLoader.constructComponent(PageLoader.java:408) org.apache.tapestry.pageload.PageLoader.loadPage(PageLoader.java:639) $IPageLoader_11ee0816045.loadPage($IPageLoader_11ee0816045.java) $IPageLoader_11ee0816046.loadPage($IPageLoader_11ee0816046.java) org.apache.tapestry.pageload.PageSource.makeObject(PageSource.java:152) org.apache.commons.pool.impl.TapestryKeyedObjectPool.borrowObject(TapestryKeyedObjectPool.java:971) org.apache.tapestry.pageload.PageSource.getPage(PageSource.java:176) $IPageSource_11ee0815fbf.getPage($IPageSource_11ee0815fbf.java) org.apache.tapestry.engine.RequestCycle.loadPage(RequestCycle.java:241) org.apache.tapestry.engine.RequestCycle.getPage(RequestCycle.java:228) com.adaptiveplanning.ui.page.Login.attemptLogin(Login.java:399) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) java.lang.reflect.Method.invoke(Unknown Source) org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeTargetMethod(ListenerMethodInvokerImpl.java:276) org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListenerMethod(ListenerMethodInvokerImpl.java:221)
Re: [T4.1] OGNL performance problem (serialization)
I found tapestry-prop-1.0.0 at http://howardlewisship.com/tapestry-javaforge/tapestry-prop/. I cannot seem to get it to work in 4.1.3 or 4.1.6. In both cases when I use it on a simple expression I get the exception below. I assumed that this was expected and that tapestry-prop was not supposed to work in 4.1.3+. Did I just do something wrong, and can I get it to work somehow? I would really prefer this if I can get it working. The alternative seems to be to re-structure my entire application to put ALL potentially slow computation in pageBeginRender, resulting in all ognl expressions being simple getters/setters. That would be a lot of work and I think it would not be a very clean solution. Does anyone have another approach? -- exception follows -- javassist.NotFoundException Stack Trace: javassist.ClassPool.get(ClassPool.java:436) org.apache.tapestry.enhance.CtClassSource.getCtClass(CtClassSource.java:50) org.apache.tapestry.enhance.AbstractFab.convertClass(AbstractFab.java:82) org.apache.tapestry.enhance.ClassFabImpl.addField(ClassFabImpl.java:238) com.javaforge.tapestry.prop.PropertyAccessorClassFactoryImpl.constructClass(PropertyAccessorClassFactoryImpl.java:74) $PropertyAccessorClassFactory_11ee0816124.constructClass($PropertyAccessorClassFactory_11ee0816124.java) $PropertyAccessorClassFactory_11ee0816123.constructClass($PropertyAccessorClassFactory_11ee0816123.java) com.javaforge.tapestry.prop.PropertyAccessorSourceImpl.createNewAccessorClass(PropertyAccessorSourceImpl.java:139) com.javaforge.tapestry.prop.PropertyAccessorSourceImpl.getCachedPropertyAccessorClass(PropertyAccessorSourceImpl.java:87) com.javaforge.tapestry.prop.PropertyAccessorSourceImpl.getAccessor(PropertyAccessorSourceImpl.java:55) $PropertyAccessorSource_11ee0816122.getAccessor($PropertyAccessorSource_11ee0816122.java) $PropertyAccessorSource_11ee0816121.getAccessor($PropertyAccessorSource_11ee0816121.java) com.javaforge.tapestry.prop.PropertyAccessorBindingFactory.createBinding(PropertyAccessorBindingFactory.java:36) $BindingFactory_11ee08160db.createBinding($BindingFactory_11ee08160db.java) $BindingFactory_11ee08160da.createBinding($BindingFactory_11ee08160da.java) org.apache.tapestry.services.impl.BindingSourceImpl.createBinding(BindingSourceImpl.java:99) $BindingSource_11ee0815f8d.createBinding($BindingSource_11ee0815f8d.java) org.apache.tapestry.services.impl.ComponentTemplateLoaderLogic.addTemplateBindings(ComponentTemplateLoaderLogic.java:277) org.apache.tapestry.services.impl.ComponentTemplateLoaderLogic.process(ComponentTemplateLoaderLogic.java:182) org.apache.tapestry.services.impl.ComponentTemplateLoaderLogic.process(ComponentTemplateLoaderLogic.java:98) org.apache.tapestry.services.impl.ComponentTemplateLoaderLogic.loadTemplate(ComponentTemplateLoaderLogic.java:75) org.apache.tapestry.services.impl.ComponentTemplateLoaderImpl.loadTemplate(ComponentTemplateLoaderImpl.java:60) $ComponentTemplateLoader_11ee0816051.loadTemplate($ComponentTemplateLoader_11ee0816051.java) org.apache.tapestry.pageload.PageLoader.loadTemplateForComponent(PageLoader.java:673) org.apache.tapestry.BaseComponent.readTemplate(BaseComponent.java:92) org.apache.tapestry.BaseComponent.finishLoad(BaseComponent.java:122) $Announcement_14.finishLoad($Announcement_14.java) org.apache.tapestry.pageload.PageLoader.constructComponent(PageLoader.java:408) org.apache.tapestry.pageload.PageLoader.loadPage(PageLoader.java:639) $IPageLoader_11ee0816045.loadPage($IPageLoader_11ee0816045.java) $IPageLoader_11ee0816046.loadPage($IPageLoader_11ee0816046.java) org.apache.tapestry.pageload.PageSource.makeObject(PageSource.java:152) org.apache.commons.pool.impl.TapestryKeyedObjectPool.borrowObject(TapestryKeyedObjectPool.java:971) org.apache.tapestry.pageload.PageSource.getPage(PageSource.java:176) $IPageSource_11ee0815fbf.getPage($IPageSource_11ee0815fbf.java) org.apache.tapestry.engine.RequestCycle.loadPage(RequestCycle.java:241) org.apache.tapestry.engine.RequestCycle.getPage(RequestCycle.java:228) com.adaptiveplanning.ui.page.Login.attemptLogin(Login.java:399) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) java.lang.reflect.Method.invoke(Unknown Source) org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeTargetMethod(ListenerMethodInvokerImpl.java:276) org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListenerMethod(ListenerMethodInvokerImpl.java:221) org.apache.tapestry.listener.ListenerMethodInvokerImpl.searchAndInvoke(ListenerMethodInvokerImpl.java:157) org.apache.tapestry.listener.ListenerMethodInvokerImpl.invokeListenerMethod(ListenerMethodInvokerImpl.java:80) org.apache.tapestry.listener.SyntheticListener.actionTriggered(SyntheticListener.java:52)
Re: [T4.1] OGNL performance problem (serialization)
It looks like the issue you mentioned was fixed in OGNL 2.7.2. In production I am using OGNL 2.7.1 that comes with Tapestry 4.1.3, but I have reproduced the problem with OGNL 2.7.3 that comes with T4.1.6. So either there was a regression or I am running into a different problem? Thanks, Aaron Ben Tomasini wrote: What version of OGNL are you using? There is a known serious issue affecting 2.6.11: http://jira.opensymphony.com/browse/OGNL-141 http://blog.opencomponentry.com/2008/02/01/ognl-272-released/ Ben On Fri, Jan 9, 2009 at 4:42 PM, Aaron Kaminsky aar...@adaptiveplanning.comwrote: Hi all, I am having some serious performance issues with OGNL in my production environment (Apache/Tomcat with Tapestry 4.1.3). I have also reproduced the problem in a test environment using Tomcat with Tapestry 4.1.6. The situation is related to the caching serialization question I had earlier, but that question got no takers. Now that it has become an issue for me in production, I am hoping this test case will generate some advice from anyone who has already dealt with this. As a simple test case I have two pages, SlowPage and FastPage. My problem is that sometimes the fast page is blocked behind the slow page. In my application I do have some actions that result in very long hits ( 10 minutes). This is expected for that action, but it is not expected that other hits become blocked by this single long running hit. Here is my test case. See the code below. If I start Tomcat fresh and open two different browsers, I can first hit SlowPage, then in the other browser hit FastPage. The OGNL expression cache locks while evaluating the expression on SlowPage, and does not release the lock to allow FastPage to proceed until it is done. The result is that all un-cached expressions are blocked for the duration. So, has anyone else run into this? Is it a best practice to never put expensive operations as OGNL expressions? That is unexpected, so I am still hoping that there is another way around this problem. Note that if the experiment is repeated the expression is not recompiled, I think. At least, the hits are no longer blocked. TestPage.java public abstract class TestPage extends BasePage { public String getSlowString() { // ... cut here, wait 20 second return This takes at least 20 seconds to return; } public String getFastString() { // no waiting here return This string is fast; } } Then I have two simple pages, each using the TestPage class and having a single Insert component: SlowPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification SlowPage.html html headtitleSlow Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:slowStringSlow String/span /body /span /html FastPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification FastPage.html html headtitleFast Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:fastStringFast String/span /body /span /html Here is my earlier message, to continue the thread (from 2008-07-03): Hi all, I am struggling to understand what is going on with OGNL compilation/caching in Tapestry 4.1.3. My first question is regarding the caching of compiled OGNL expressions. From my reading of the code it looks like the entire application serializes through the ExpressionCacheImpl.java lock. What am I missing? Doesn't that mean that if I have an expression that is very expensive to evaluate that all other hits will be blocked with that expression is evaluated? Or is that not what the compilation does? Has anyone else experienced any performance problems that they can trace to this locking/serialization? My second question has been asked before on this list, but has not been answered (I think). Why is a given OGNL expression evaluated multiple times in a single instance? Is there any way to turn that off or work around it? I have been trying to dig into the source code to figure this out, but I think I am getting lost in the details. Can someone please explain this or point me at the information I need? Thanks and regards, Aaron - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- See how easy it can be to move beyond spreadsheets for budgeting, forecasting and reporting! Try Adaptive Planning now: Trial Enterprise Edition | Use Free Express Edition
Re: [T4.1] OGNL performance problem (serialization)
I did try, and can confirm that tapestry-prop does not work with T4.1.3 or 4.1.6. -Aaron Kevin Menard wrote: It's been a while, but I'm pretty sure that tapestry-prop does not work with T4.1 -- See how easy it can be to move beyond spreadsheets for budgeting, forecasting and reporting! Try Adaptive Planning now: Trial Enterprise Edition | Use Free Express Edition - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
tapestry-prop had a 1.0.0 version that is compatible with 4.1.3 and on - not sure if there's any public repo that hosts it... if i dont find one, i can deploy it to tacos repo soon On Mon, Jan 12, 2009 at 5:38 PM, Aaron Kaminsky aar...@adaptiveplanning.com wrote: I did try, and can confirm that tapestry-prop does not work with T4.1.3 or 4.1.6. -Aaron Kevin Menard wrote: It's been a while, but I'm pretty sure that tapestry-prop does not work with T4.1 -- See how easy it can be to move beyond spreadsheets for budgeting, forecasting and reporting! Try Adaptive Planning now: Trial Enterprise Edition | Use Free Express Edition - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Andreas Andreou - andy...@apache.org - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
It's been a while, but I'm pretty sure that tapestry-prop does not work with T4.1 -- Kevin On Fri, Jan 9, 2009 at 10:44 PM, Jonathan Barker jonathan.theit...@gmail.com wrote: Aaron, Not that these are solutions, but sometimes a good workaround will do the trick. Have you tried using tapestry-prop? It was more useful before ognl was optimized, and I've read about possible incompatibilities with later versions of T4, but it's worth a try. Have you tried specifying the value binding within the Java file? It's some serious baggage to have to declare an Insert component, but again, if it fixes your problem... Good luck. Jonathan -Original Message- From: Aaron Kaminsky [mailto:aar...@adaptiveplanning.com] Sent: Friday, January 09, 2009 19:42 To: Tapestry users Subject: [T4.1] OGNL performance problem (serialization) Hi all, I am having some serious performance issues with OGNL in my production environment (Apache/Tomcat with Tapestry 4.1.3). I have also reproduced the problem in a test environment using Tomcat with Tapestry 4.1.6. The situation is related to the caching serialization question I had earlier, but that question got no takers. Now that it has become an issue for me in production, I am hoping this test case will generate some advice from anyone who has already dealt with this. As a simple test case I have two pages, SlowPage and FastPage. My problem is that sometimes the fast page is blocked behind the slow page. In my application I do have some actions that result in very long hits ( 10 minutes). This is expected for that action, but it is not expected that other hits become blocked by this single long running hit. Here is my test case. See the code below. If I start Tomcat fresh and open two different browsers, I can first hit SlowPage, then in the other browser hit FastPage. The OGNL expression cache locks while evaluating the expression on SlowPage, and does not release the lock to allow FastPage to proceed until it is done. The result is that all un-cached expressions are blocked for the duration. So, has anyone else run into this? Is it a best practice to never put expensive operations as OGNL expressions? That is unexpected, so I am still hoping that there is another way around this problem. Note that if the experiment is repeated the expression is not recompiled, I think. At least, the hits are no longer blocked. TestPage.java public abstract class TestPage extends BasePage { public String getSlowString() { // ... cut here, wait 20 second return This takes at least 20 seconds to return; } public String getFastString() { // no waiting here return This string is fast; } } Then I have two simple pages, each using the TestPage class and having a single Insert component: SlowPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification SlowPage.html html headtitleSlow Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:slowStringSlow String/span /body /span /html FastPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification FastPage.html html headtitleFast Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:fastStringFast String/span /body /span /html Here is my earlier message, to continue the thread (from 2008-07-03): Hi all, I am struggling to understand what is going on with OGNL compilation/caching in Tapestry 4.1.3. My first question is regarding the caching of compiled OGNL expressions. From my reading of the code it looks like the entire application serializes through the ExpressionCacheImpl.java lock. What am I missing? Doesn't that mean that if I have an expression that is very expensive to evaluate that all other hits will be blocked with that expression is evaluated? Or is that not what the compilation does? Has anyone else experienced any performance problems that they can trace to this locking/serialization? My second question has been asked before on this list, but has not been answered (I think). Why is a given OGNL expression evaluated multiple times in a single instance? Is there any way to turn that off or work around it? I have been trying to dig into the source code to figure this out, but I think I am getting lost in the details. Can someone please explain this or point me at the information I need? Thanks and regards, Aaron
Re: [T4.1] OGNL performance problem (serialization)
On Fri, Jan 9, 2009 at 7:42 PM, Aaron Kaminsky aar...@adaptiveplanning.com wrote: My second question has been asked before on this list, but has not been answered (I think). Why is a given OGNL expression evaluated multiple times in a single instance? Is there any way to turn that off or work around it? I'm no longer sure what the answer is here. It was added when OGNL was resurrected. I'm not sure if it was a benchmarking thing or used to prime a cache. In any event, I agree that it's quite annoying. I think it was supposed to get fixed, but never did. As far as I know, the issue is on the OGNL side. The workaround is to push whatever you can of your expression into the page class and then use the @Cached annotation from Tacos. -- Kevin - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
What version of OGNL are you using? There is a known serious issue affecting 2.6.11: http://jira.opensymphony.com/browse/OGNL-141 http://blog.opencomponentry.com/2008/02/01/ognl-272-released/ Ben On Fri, Jan 9, 2009 at 4:42 PM, Aaron Kaminsky aar...@adaptiveplanning.comwrote: Hi all, I am having some serious performance issues with OGNL in my production environment (Apache/Tomcat with Tapestry 4.1.3). I have also reproduced the problem in a test environment using Tomcat with Tapestry 4.1.6. The situation is related to the caching serialization question I had earlier, but that question got no takers. Now that it has become an issue for me in production, I am hoping this test case will generate some advice from anyone who has already dealt with this. As a simple test case I have two pages, SlowPage and FastPage. My problem is that sometimes the fast page is blocked behind the slow page. In my application I do have some actions that result in very long hits ( 10 minutes). This is expected for that action, but it is not expected that other hits become blocked by this single long running hit. Here is my test case. See the code below. If I start Tomcat fresh and open two different browsers, I can first hit SlowPage, then in the other browser hit FastPage. The OGNL expression cache locks while evaluating the expression on SlowPage, and does not release the lock to allow FastPage to proceed until it is done. The result is that all un-cached expressions are blocked for the duration. So, has anyone else run into this? Is it a best practice to never put expensive operations as OGNL expressions? That is unexpected, so I am still hoping that there is another way around this problem. Note that if the experiment is repeated the expression is not recompiled, I think. At least, the hits are no longer blocked. TestPage.java public abstract class TestPage extends BasePage { public String getSlowString() { // ... cut here, wait 20 second return This takes at least 20 seconds to return; } public String getFastString() { // no waiting here return This string is fast; } } Then I have two simple pages, each using the TestPage class and having a single Insert component: SlowPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification SlowPage.html html headtitleSlow Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:slowStringSlow String/span /body /span /html FastPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification FastPage.html html headtitleFast Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:fastStringFast String/span /body /span /html Here is my earlier message, to continue the thread (from 2008-07-03): Hi all, I am struggling to understand what is going on with OGNL compilation/caching in Tapestry 4.1.3. My first question is regarding the caching of compiled OGNL expressions. From my reading of the code it looks like the entire application serializes through the ExpressionCacheImpl.java lock. What am I missing? Doesn't that mean that if I have an expression that is very expensive to evaluate that all other hits will be blocked with that expression is evaluated? Or is that not what the compilation does? Has anyone else experienced any performance problems that they can trace to this locking/serialization? My second question has been asked before on this list, but has not been answered (I think). Why is a given OGNL expression evaluated multiple times in a single instance? Is there any way to turn that off or work around it? I have been trying to dig into the source code to figure this out, but I think I am getting lost in the details. Can someone please explain this or point me at the information I need? Thanks and regards, Aaron - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
[T4.1] OGNL performance problem (serialization)
Hi all, I am having some serious performance issues with OGNL in my production environment (Apache/Tomcat with Tapestry 4.1.3). I have also reproduced the problem in a test environment using Tomcat with Tapestry 4.1.6. The situation is related to the caching serialization question I had earlier, but that question got no takers. Now that it has become an issue for me in production, I am hoping this test case will generate some advice from anyone who has already dealt with this. As a simple test case I have two pages, SlowPage and FastPage. My problem is that sometimes the fast page is blocked behind the slow page. In my application I do have some actions that result in very long hits ( 10 minutes). This is expected for that action, but it is not expected that other hits become blocked by this single long running hit. Here is my test case. See the code below. If I start Tomcat fresh and open two different browsers, I can first hit SlowPage, then in the other browser hit FastPage. The OGNL expression cache locks while evaluating the expression on SlowPage, and does not release the lock to allow FastPage to proceed until it is done. The result is that all un-cached expressions are blocked for the duration. So, has anyone else run into this? Is it a best practice to never put expensive operations as OGNL expressions? That is unexpected, so I am still hoping that there is another way around this problem. Note that if the experiment is repeated the expression is not recompiled, I think. At least, the hits are no longer blocked. TestPage.java public abstract class TestPage extends BasePage { public String getSlowString() { // ... cut here, wait 20 second return This takes at least 20 seconds to return; } public String getFastString() { // no waiting here return This string is fast; } } Then I have two simple pages, each using the TestPage class and having a single Insert component: SlowPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification SlowPage.html html headtitleSlow Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:slowStringSlow String/span /body /span /html FastPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification FastPage.html html headtitleFast Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:fastStringFast String/span /body /span /html Here is my earlier message, to continue the thread (from 2008-07-03): Hi all, I am struggling to understand what is going on with OGNL compilation/caching in Tapestry 4.1.3. My first question is regarding the caching of compiled OGNL expressions. From my reading of the code it looks like the entire application serializes through the ExpressionCacheImpl.java lock. What am I missing? Doesn't that mean that if I have an expression that is very expensive to evaluate that all other hits will be blocked with that expression is evaluated? Or is that not what the compilation does? Has anyone else experienced any performance problems that they can trace to this locking/serialization? My second question has been asked before on this list, but has not been answered (I think). Why is a given OGNL expression evaluated multiple times in a single instance? Is there any way to turn that off or work around it? I have been trying to dig into the source code to figure this out, but I think I am getting lost in the details. Can someone please explain this or point me at the information I need? Thanks and regards, Aaron - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: [T4.1] OGNL performance problem (serialization)
Aaron, Not that these are solutions, but sometimes a good workaround will do the trick. Have you tried using tapestry-prop? It was more useful before ognl was optimized, and I've read about possible incompatibilities with later versions of T4, but it's worth a try. Have you tried specifying the value binding within the Java file? It's some serious baggage to have to declare an Insert component, but again, if it fixes your problem... Good luck. Jonathan -Original Message- From: Aaron Kaminsky [mailto:aar...@adaptiveplanning.com] Sent: Friday, January 09, 2009 19:42 To: Tapestry users Subject: [T4.1] OGNL performance problem (serialization) Hi all, I am having some serious performance issues with OGNL in my production environment (Apache/Tomcat with Tapestry 4.1.3). I have also reproduced the problem in a test environment using Tomcat with Tapestry 4.1.6. The situation is related to the caching serialization question I had earlier, but that question got no takers. Now that it has become an issue for me in production, I am hoping this test case will generate some advice from anyone who has already dealt with this. As a simple test case I have two pages, SlowPage and FastPage. My problem is that sometimes the fast page is blocked behind the slow page. In my application I do have some actions that result in very long hits ( 10 minutes). This is expected for that action, but it is not expected that other hits become blocked by this single long running hit. Here is my test case. See the code below. If I start Tomcat fresh and open two different browsers, I can first hit SlowPage, then in the other browser hit FastPage. The OGNL expression cache locks while evaluating the expression on SlowPage, and does not release the lock to allow FastPage to proceed until it is done. The result is that all un-cached expressions are blocked for the duration. So, has anyone else run into this? Is it a best practice to never put expensive operations as OGNL expressions? That is unexpected, so I am still hoping that there is another way around this problem. Note that if the experiment is repeated the expression is not recompiled, I think. At least, the hits are no longer blocked. TestPage.java public abstract class TestPage extends BasePage { public String getSlowString() { // ... cut here, wait 20 second return This takes at least 20 seconds to return; } public String getFastString() { // no waiting here return This string is fast; } } Then I have two simple pages, each using the TestPage class and having a single Insert component: SlowPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification SlowPage.html html headtitleSlow Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:slowStringSlow String/span /body /span /html FastPage.page ?xml version=1.0 encoding=UTF-8? !DOCTYPE page-specification PUBLIC -//Apache Software Foundation//Tapestry Specification 4.0//EN http://tapestry.apache.org/dtd/Tapestry_4_0.dtd; page-specification class=com.adaptiveplanning.ui.page.TestPage /page-specification FastPage.html html headtitleFast Page/title/head span jwcid=$content$ body span jwcid=@Insert value=ognl:fastStringFast String/span /body /span /html Here is my earlier message, to continue the thread (from 2008-07-03): Hi all, I am struggling to understand what is going on with OGNL compilation/caching in Tapestry 4.1.3. My first question is regarding the caching of compiled OGNL expressions. From my reading of the code it looks like the entire application serializes through the ExpressionCacheImpl.java lock. What am I missing? Doesn't that mean that if I have an expression that is very expensive to evaluate that all other hits will be blocked with that expression is evaluated? Or is that not what the compilation does? Has anyone else experienced any performance problems that they can trace to this locking/serialization? My second question has been asked before on this list, but has not been answered (I think). Why is a given OGNL expression evaluated multiple times in a single instance? Is there any way to turn that off or work around it? I have been trying to dig into the source code to figure this out, but I think I am getting lost in the details. Can someone please explain this or point me at the information I need? Thanks and regards, Aaron - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org