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> > <head><title>Slow Page</title></head> > <span jwcid="$content$"> > > <body> > <span jwcid="@Insert" value="ognl:slowString">Slow 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> > <head><title>Fast Page</title></head> > <span jwcid="$content$"> > > <body> > <span jwcid="@Insert" value="ognl:fastString">Fast 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
