tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlo Simbag (JIRA)" <j...@apache.org>
Subject [jira] Updated: (TAP5-256) Page Pool Limit exhausted when exception occurs (during PageAttached lifecycle) on a link
Date Wed, 08 Oct 2008 04:31:44 GMT

     [ https://issues.apache.org/jira/browse/TAP5-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Carlo Simbag updated TAP5-256:

    Attachment: PagePoolLoadTest.jmx

Sample Tapestry Application and JMeter test

> Page Pool Limit exhausted when exception occurs (during PageAttached lifecycle) on a
> -----------------------------------------------------------------------------------------
>                 Key: TAP5-256
>                 URL: https://issues.apache.org/jira/browse/TAP5-256
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.0.15
>            Reporter: Carlo Simbag
>         Attachments: PagePoolLoadTest.jmx, tutorial1.zip
> Whenever an exception occurs on a linked page (PageA in the attached example code), the
size of the "inUse" LinkedList is never reset.   The reason for this is that Tapestry has
no chance to mark the page causing the exception (PageA) as dirty and add it to the request
page cache.   Therefore at the end of the request, when the thread cleanup event occurs, the
page in error is never removed (when dirty) and released.   However the requested page (PageB
in the attached JMeter test) is marked as dirty and added to the request page cache and is
subsequently removed and released.
> I have attached a sample project which has 3 pages (PageA, PageB, and PageC).  On each
page, there is side menu that links to PageA, B and C.   In PageA during the PageAttached
lifecycle, I have added a Runtime exception (note that in our production environment we are
getting Connection reset exceptions).  To run this application, you need to do the following:
>  - Extract the attached tutorial1.zip 
>  - mvn clean install
> -  mvn jetty:run
> A Jmeter test (PagePoolLoadTest.jmx) has also been provided, to automatically go to PageB
and assert that the exception generated by PageA exists as part of the response.  The test
has 20 concurrent users which should run successfully during the first attempt.  However,
during the second attempt, the test should fail because Tapestry will report that page pool
limit exceeded for PageA eventhough there are only 20 concurrent users.  
> The patch I applied to our production version of Tapestry (5.0.15) is to modify the RequestpageCacheImpl
get method to catch the RuntimeException and mark the page as dirty and add it to the request
page cache:
>     public Page get(String logicalPageName)
>     {
>         Page page = cache.get(logicalPageName);
>         if (page == null)
>         {
>             page = pagePool.checkout(logicalPageName);
>             try {
> 				page.attached();
> 				cache.put(logicalPageName, page);
> 			} catch(RuntimeException e) {
> 				page.incrementDirtyCount();
> 				cache.put(logicalPageName, page);
> 				throw e;
> 			}
>         }
>         return page;
>     }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message