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> >> <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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
