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.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
--
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
