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.com>wrote: > 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 > >
