You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Aaron Kaminsky <aa...@adaptiveplanning.com> on 2009/01/10 01:42:25 UTC
[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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Aaron Kaminsky <aa...@adaptiveplanning.com>.
Hello Andreas,
Thank you for spending the time to look at this, I appreciate it. I can
confirm that I do not have (actually have never had)
org.apache.tapestry.disable-caching set, so it should be using the
default of false. I believe this is true because I can see in my
debugger that pages are reused from the pool, so I cannot have caching
disabled.
Further experimentation has shown a few more details. First of all,
this problem only occurs when the cache is relatively empty (i.e.
immediately after a restart). After each of the expressions in question
have been evaluated and placed in the cache they are no longer
blocking. However, I can still reproduce this most of the time in the
following way.
Restart my application to make sure the cache is empty. Open two
different browsers. Point the first browser to
http://localhost/app?service=page&page=slowPage and hit go. How the
browser starts to spin and I can see in my log that the hit is starting
to process. Now try to hit any other page containing OGNL with the
second browser, it will spin until after the first hit is "almost"
done. I will say that this is only most of the time, not all the time.
I think the race condition is that sometimes it takes long enough for
the first hit to get into the expression caching methods that I
sometimes start the second browser too soon and it gets there first.
Also, as each OGNL expression is initially evaluated three times, the
second page will often still beat the first (although it still has to
wait for 1 or 2 evaluations of the slow expression). Hopefully that is
not too confusing a description. From the debugger I can see what is
happening. When the first expression gets into getCompiledExpression in
ExpressionCacheImpl.java it grabs a lock and then starts the
evaluation. All other expressions that are not yet in the cache will
have to wait for the long expression to be evaluated. So once
everything is in the cache, no problem. Also, even when things are not
all in the cache, sometimes the fast expressions get there first and the
problem is less obvious.
I was hoping to find out some way to avoid this blocking, but it seems
as though without using something like prop (which does not work for
this version) I am stuck with it.
Can anyone shed any more light on this expression cache issue?
Thanks again for all your help!
Regards,
Aaron
Andreas Andreou wrote:
> 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
> <aa...@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)
>> 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)
>> org.apache.tapestry.listener.ListenerInvokerTerminator.invokeListener(ListenerInvokerTerminator.java:50)
>> $ListenerInvoker_11ee0815fb5.invokeListener($ListenerInvoker_11ee0815fb5.java)
>> org.apache.tapestry.form.Form.renderComponent(Form.java:200)
>> org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:724)
>> org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:187)
>> org.apache.tapestry.form.Form.rewind(Form.java:269)
>> org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java:469)
>> org.apache.tapestry.form.Form.trigger(Form.java:280)
>> org.apache.tapestry.engine.DirectService.triggerComponent(DirectService.java:166)
>> org.apache.tapestry.engine.DirectService.service(DirectService.java:142)
>> $IEngineService_11ee0816031.service($IEngineService_11ee0816031.java)
>> org.apache.tapestry.services.impl.EngineServiceInnerProxy.service(EngineServiceInnerProxy.java:77)
>> org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(EngineServiceOuterProxy.java:72)
>> org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:241)
>> org.apache.tapestry.services.impl.InvokeEngineTerminator.service(InvokeEngineTerminator.java:54)
>> $WebRequestServicer_11ee081600a.service($WebRequestServicer_11ee081600a.java)
>> $WebRequestServicer_11ee0816009.service($WebRequestServicer_11ee0816009.java)
>> com.adaptiveplanning.util.TokenizedRequestFilter.service(TokenizedRequestFilter.java:65)
>> $WebRequestServicerFilter_11ee0816008.service($WebRequestServicerFilter_11ee0816008.java)
>> $WebRequestServicerFilter_11ee0816007.service($WebRequestServicerFilter_11ee0816007.java)
>> $WebRequestServicer_11ee081600b.service($WebRequestServicer_11ee081600b.java)
>> $WebRequestServicer_11ee0816004.service($WebRequestServicer_11ee0816004.java)
>> $WebRequestServicer_11ee0816003.service($WebRequestServicer_11ee0816003.java)
>> org.apache.tapestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServicerPipelineBridge.java:61)
>> $ServletRequestServicer_11ee0815fea.service($ServletRequestServicer_11ee0815fea.java)
>> $ServletRequestServicer_11ee0815fe9.service($ServletRequestServicer_11ee0815fe9.java)
>> org.apache.tapestry.request.DecodedRequestInjector.service(DecodedRequestInjector.java:55)
>> $ServletRequestServicerFilter_11ee0815fe6.service($ServletRequestServicerFilter_11ee0815fe6.java)
>> $ServletRequestServicerFilter_11ee0815fe5.service($ServletRequestServicerFilter_11ee0815fe5.java)
>> $ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
>> org.apache.tapestry.multipart.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52)
>> $ServletRequestServicerFilter_11ee0815fe4.service($ServletRequestServicerFilter_11ee0815fe4.java)
>> $ServletRequestServicerFilter_11ee0815fe3.service($ServletRequestServicerFilter_11ee0815fe3.java)
>> $ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
>> org.apache.tapestry.services.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53)
>> $ServletRequestServicerFilter_11ee0815fe8.service($ServletRequestServicerFilter_11ee0815fe8.java)
>> $ServletRequestServicerFilter_11ee0815fe7.service($ServletRequestServicerFilter_11ee0815fe7.java)
>> $ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
>> $ServletRequestServicer_11ee0815fde.service($ServletRequestServicer_11ee0815fde.java)
>> $ServletRequestServicer_11ee0815fdd.service($ServletRequestServicer_11ee0815fdd.java)
>> org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:126)
>> org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.java:171)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> com.adaptiveplanning.system.APRequestFilter.doFilter(APRequestFilter.java:68)
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> java.lang.Thread.run(Unknown Source)
>>
>> Thanks,
>> Aaron
>>
>> Andreas Andreou wrote:
>>
>>> 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
>>> <aa...@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Andreas Andreou <an...@di.uoa.gr>.
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
<aa...@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)
> 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)
> org.apache.tapestry.listener.ListenerInvokerTerminator.invokeListener(ListenerInvokerTerminator.java:50)
> $ListenerInvoker_11ee0815fb5.invokeListener($ListenerInvoker_11ee0815fb5.java)
> org.apache.tapestry.form.Form.renderComponent(Form.java:200)
> org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:724)
> org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:187)
> org.apache.tapestry.form.Form.rewind(Form.java:269)
> org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java:469)
> org.apache.tapestry.form.Form.trigger(Form.java:280)
> org.apache.tapestry.engine.DirectService.triggerComponent(DirectService.java:166)
> org.apache.tapestry.engine.DirectService.service(DirectService.java:142)
> $IEngineService_11ee0816031.service($IEngineService_11ee0816031.java)
> org.apache.tapestry.services.impl.EngineServiceInnerProxy.service(EngineServiceInnerProxy.java:77)
> org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(EngineServiceOuterProxy.java:72)
> org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:241)
> org.apache.tapestry.services.impl.InvokeEngineTerminator.service(InvokeEngineTerminator.java:54)
> $WebRequestServicer_11ee081600a.service($WebRequestServicer_11ee081600a.java)
> $WebRequestServicer_11ee0816009.service($WebRequestServicer_11ee0816009.java)
> com.adaptiveplanning.util.TokenizedRequestFilter.service(TokenizedRequestFilter.java:65)
> $WebRequestServicerFilter_11ee0816008.service($WebRequestServicerFilter_11ee0816008.java)
> $WebRequestServicerFilter_11ee0816007.service($WebRequestServicerFilter_11ee0816007.java)
> $WebRequestServicer_11ee081600b.service($WebRequestServicer_11ee081600b.java)
> $WebRequestServicer_11ee0816004.service($WebRequestServicer_11ee0816004.java)
> $WebRequestServicer_11ee0816003.service($WebRequestServicer_11ee0816003.java)
> org.apache.tapestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServicerPipelineBridge.java:61)
> $ServletRequestServicer_11ee0815fea.service($ServletRequestServicer_11ee0815fea.java)
> $ServletRequestServicer_11ee0815fe9.service($ServletRequestServicer_11ee0815fe9.java)
> org.apache.tapestry.request.DecodedRequestInjector.service(DecodedRequestInjector.java:55)
> $ServletRequestServicerFilter_11ee0815fe6.service($ServletRequestServicerFilter_11ee0815fe6.java)
> $ServletRequestServicerFilter_11ee0815fe5.service($ServletRequestServicerFilter_11ee0815fe5.java)
> $ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
> org.apache.tapestry.multipart.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52)
> $ServletRequestServicerFilter_11ee0815fe4.service($ServletRequestServicerFilter_11ee0815fe4.java)
> $ServletRequestServicerFilter_11ee0815fe3.service($ServletRequestServicerFilter_11ee0815fe3.java)
> $ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
> org.apache.tapestry.services.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53)
> $ServletRequestServicerFilter_11ee0815fe8.service($ServletRequestServicerFilter_11ee0815fe8.java)
> $ServletRequestServicerFilter_11ee0815fe7.service($ServletRequestServicerFilter_11ee0815fe7.java)
> $ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
> $ServletRequestServicer_11ee0815fde.service($ServletRequestServicer_11ee0815fde.java)
> $ServletRequestServicer_11ee0815fdd.service($ServletRequestServicer_11ee0815fdd.java)
> org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:126)
> org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.java:171)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> com.adaptiveplanning.system.APRequestFilter.doFilter(APRequestFilter.java:68)
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> java.lang.Thread.run(Unknown Source)
>
> Thanks,
> Aaron
>
> Andreas Andreou wrote:
>>
>> 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
>> <aa...@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Aaron Kaminsky <aa...@adaptiveplanning.com>.
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)
org.apache.tapestry.listener.ListenerInvokerTerminator.invokeListener(ListenerInvokerTerminator.java:50)
$ListenerInvoker_11ee0815fb5.invokeListener($ListenerInvoker_11ee0815fb5.java)
org.apache.tapestry.form.Form.renderComponent(Form.java:200)
org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:724)
org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:187)
org.apache.tapestry.form.Form.rewind(Form.java:269)
org.apache.tapestry.engine.RequestCycle.rewindForm(RequestCycle.java:469)
org.apache.tapestry.form.Form.trigger(Form.java:280)
org.apache.tapestry.engine.DirectService.triggerComponent(DirectService.java:166)
org.apache.tapestry.engine.DirectService.service(DirectService.java:142)
$IEngineService_11ee0816031.service($IEngineService_11ee0816031.java)
org.apache.tapestry.services.impl.EngineServiceInnerProxy.service(EngineServiceInnerProxy.java:77)
org.apache.tapestry.services.impl.EngineServiceOuterProxy.service(EngineServiceOuterProxy.java:72)
org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:241)
org.apache.tapestry.services.impl.InvokeEngineTerminator.service(InvokeEngineTerminator.java:54)
$WebRequestServicer_11ee081600a.service($WebRequestServicer_11ee081600a.java)
$WebRequestServicer_11ee0816009.service($WebRequestServicer_11ee0816009.java)
com.adaptiveplanning.util.TokenizedRequestFilter.service(TokenizedRequestFilter.java:65)
$WebRequestServicerFilter_11ee0816008.service($WebRequestServicerFilter_11ee0816008.java)
$WebRequestServicerFilter_11ee0816007.service($WebRequestServicerFilter_11ee0816007.java)
$WebRequestServicer_11ee081600b.service($WebRequestServicer_11ee081600b.java)
$WebRequestServicer_11ee0816004.service($WebRequestServicer_11ee0816004.java)
$WebRequestServicer_11ee0816003.service($WebRequestServicer_11ee0816003.java)
org.apache.tapestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServicerPipelineBridge.java:61)
$ServletRequestServicer_11ee0815fea.service($ServletRequestServicer_11ee0815fea.java)
$ServletRequestServicer_11ee0815fe9.service($ServletRequestServicer_11ee0815fe9.java)
org.apache.tapestry.request.DecodedRequestInjector.service(DecodedRequestInjector.java:55)
$ServletRequestServicerFilter_11ee0815fe6.service($ServletRequestServicerFilter_11ee0815fe6.java)
$ServletRequestServicerFilter_11ee0815fe5.service($ServletRequestServicerFilter_11ee0815fe5.java)
$ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
org.apache.tapestry.multipart.MultipartDecoderFilter.service(MultipartDecoderFilter.java:52)
$ServletRequestServicerFilter_11ee0815fe4.service($ServletRequestServicerFilter_11ee0815fe4.java)
$ServletRequestServicerFilter_11ee0815fe3.service($ServletRequestServicerFilter_11ee0815fe3.java)
$ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
org.apache.tapestry.services.impl.SetupRequestEncoding.service(SetupRequestEncoding.java:53)
$ServletRequestServicerFilter_11ee0815fe8.service($ServletRequestServicerFilter_11ee0815fe8.java)
$ServletRequestServicerFilter_11ee0815fe7.service($ServletRequestServicerFilter_11ee0815fe7.java)
$ServletRequestServicer_11ee0815feb.service($ServletRequestServicer_11ee0815feb.java)
$ServletRequestServicer_11ee0815fde.service($ServletRequestServicer_11ee0815fde.java)
$ServletRequestServicer_11ee0815fdd.service($ServletRequestServicer_11ee0815fdd.java)
org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:126)
org.apache.tapestry.ApplicationServlet.doPost(ApplicationServlet.java:171)
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
com.adaptiveplanning.system.APRequestFilter.doFilter(APRequestFilter.java:68)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Unknown Source)
Thanks,
Aaron
Andreas Andreou wrote:
> 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
> <aa...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Andreas Andreou <an...@di.uoa.gr>.
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
<aa...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Aaron Kaminsky <aa...@adaptiveplanning.com>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Kevin Menard <ni...@gmail.com>.
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
<jo...@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:aaronk@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: [T4.1] OGNL performance problem (serialization)
Posted by Jonathan Barker <jo...@gmail.com>.
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:aaronk@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Kevin Menard <ni...@gmail.com>.
On Fri, Jan 9, 2009 at 7:42 PM, Aaron Kaminsky
<aa...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Aaron Kaminsky <aa...@adaptiveplanning.com>.
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
> <aa...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T4.1] OGNL performance problem (serialization)
Posted by Ben Tomasini <be...@gmail.com>.
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
<aa...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>