tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-1197) Eliminate page pooling using shared page instances that separate their structure from the mutable state
Date Thu, 15 Jul 2010 01:25:50 GMT

    [ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888663#action_12888663
] 

Hudson commented on TAP5-1197:
------------------------------

Integrated in tapestry-5.2-freestyle #154 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/154/])
    TAP5-1197: Only track the page's dirty count in when the page pool is enabled (it is meaningless
in the non-pooling mode)


> Eliminate page pooling using shared page instances that separate their structure from
the mutable state
> -------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-1197
>                 URL: https://issues.apache.org/jira/browse/TAP5-1197
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-core
>    Affects Versions: 5.2.0
>            Reporter: Howard M. Lewis Ship
>            Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes
it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it
via the PerThreadManager.  This will be invisible to user code; the pages will appear to be
individual instances with internal state ... but in fact, it will be a single instance (per
locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation
pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1,
while any third party libraries that contribute workers update.
> Why do all this?  For large applications with very complex pages, this will be a big
win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to
me, but apparently true) once you have a few dozen (or hundred) page instances (of each page
type) floating around.

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


Mime
View raw message