[jira] [Created] (MYFACES-3831) CacheELFaceletCacheImpl is not storing the compiled template (only when "alwaysRecompile" is enabled)
Leonardo Uribe created MYFACES-3831: --- Summary: CacheELFaceletCacheImpl is not storing the compiled template (only when "alwaysRecompile" is enabled) Key: MYFACES-3831 URL: https://issues.apache.org/jira/browse/MYFACES-3831 Project: MyFaces Core Issue Type: Bug Components: JSR-314, JSR-344 Affects Versions: 2.2.0-beta, 2.1.13 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Doing some tests over the code, I found a bug inside CacheELFaceletCacheImpl . In few words, when "alwaysRecompile" is activated, the compiled facelet is not stored properly, but only when it belongs to a template. The bug was really hard to track down, because everything works well, so I didn't see any symptom. But later on, I checked some performance measurements over the code, finding some inconsistencies with previous measurements done long time ago. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3664) JSF View Pooling (going beyond JSF Stateless Mode)
[ https://issues.apache.org/jira/browse/MYFACES-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842260#comment-13842260 ] Thomas Andraschko commented on MYFACES-3664: thanks for your effort Leo. Will you also do another performance/memory/troughput comparison after 2.2 release? Would be great! > JSF View Pooling (going beyond JSF Stateless Mode) > -- > > Key: MYFACES-3664 > URL: https://issues.apache.org/jira/browse/MYFACES-3664 > Project: MyFaces Core > Issue Type: New Feature > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: myfacesStatelessMode-12-view-pool.patch, > myfacesStatelessMode-6-view-pool.patch, myfacesStatelessMode-8-view-pool.patch > > > In the last months, I have been doing some investigations around "stateless > JSF" ideas. The intention is try to find ways to improve MyFaces Core > performance as much as possible, without lose all those nice features we all > are used to. > In summary, the justification around stateless JSF is that, if it is possible > to cut the build view time from a request, there will be an improvement from > both speed and memory perspective. This is true, but only to some point, > because the response time for a request is given by the build view, > validation/invoke application and render response time. > To get to the same goal, without sacrifice JSF stateful behavior, other > improvements has been already done (cache EL expressions, cache ids, make > tree structure lighter, ...). The idea is cache that "stateless information" > into a place where it can be reused effectively, which in this case is inside > Facelet abstract syntax tree (AST). This has worked well so far. The side > effects of enable these optimizations has been analysed, and there is a good > understanding about this. > In few words, the basic idea about stateless JSF as proposed originally by > Rudi Simic in his blog is this: > Mark the view as stateless using some attribute. > Use a pool of views, because views are not thread safe. > Before store the view in the pool, use a visitTree call to reset the fields. > Unfortunately, it was quickly found that the implementation proposed requires > a better view pool and try to reset the fields is not fail-safe, because the > component tree also stores more than just the input field values. > Additionally, it doesn't provide a way to use it for dynamic views. > Provide a thread safe implementation of UIComponent that can be reused across > threads is not a good solution, because anyway there is some information > that is inside UIComponent and should be stored per thread, and precisely > UIComponent is a place specifically designed to store that information. > Based on the previous background, the big question is if a solution based on > object pooling pattern can be done effectively for a web framework like JSF. > A good description of the technique and its trade-off can be found at: > http://en.wikipedia.org/wiki/Object_pool_pattern > In few words, the proposal is go "Beyond JSF Stateless Mode", and instead > blame the state, make it your friend. Let's just take advantage of the > stateful nature of JSF to allow reuse views fully or partially. > How? > - PSS algorithm can be used to check if a view has been modified or not, > checking its state. So, it can be used to check which components has state, > and if it is possible to provide a way to reset the state of a component to > the initial state set by the first markInitialState(), restore the state is > possible. > -If the view cannot be reset fully, it is possible to use facelets refreshing > algorithm and reuse a view partially. > - Add some additional code to recover a view instance when it is discarded, > and store it into the view pool. This requires some changes over > NavigationHandlerImpl, because it is not possible to reuse a view and store > it in the pool that is still on usage, so it is necessary to do a "deferred > navigation", changing the default ActionListenerImpl and ensure > handleNavigation() is called before end invoke application phase but outside > the visitTree() call. > - In MyFaces there exists the concept of FaceletState. It is possible to use > this concept and cache even dynamic views, because each different > FaceletState can identify an specific view structure. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Leo, one question: Is it possible to mark a view as "poolable" via code? We configure all our views via typesafe view config from CODI/DS 2013/12/4 Thomas Andraschko > Looks fine for me! > > > 2013/12/3 Leonardo Uribe > >> Hi >> >> I have been thinking about how to define the configuration for the view >> pool. The idea is add the following new web config parameters: >> >> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in >> the app, by default false) >> org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE (the number of views stored in >> the pool per key) >> org.apache.myfaces.VIEW_POOL_MAX_DYNAMIC_PARTIAL_LIMIT (the number of dyn >> views that can be used as partial) >> org.apache.myfaces.VIEW_POOL_ENTRY_MODE (weak, soft) >> org.apache.myfaces.VIEW_POOL_DEFERRED_NAVIGATION (reuse views that are >> navigated using default algorithm (increase reusal but it uses a hack that >> does not follow jsf spec) ) >> >> And include this possible extension in faces-config.xml: >> >> >> >> /* >> >> org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE >> 5 >> >> >> >> >> The idea is allow users to enable the view pool only for a part of the >> application using and override some specific view pool >> parameters. The idea is there are parts of the application that are used >> quite intensively and others that are not frequently visited. >> >> Suggestions are welcome. >> >> regards, >> >> Leonardo Uribe >> >> >> >> 2013/11/25 Martin Kočí >> >>> Hi, >>> >>> +1 for this feature in core 2.2. >>> >>> Regards, >>> >>> Kocicak >>> >>> >>> >>> 2013/11/24 Thomas Andraschko >>> Perfect. Thanks for Info. So +1 from my side. 2013/11/24 Leonardo Uribe > Hi > > 2013/11/24 Thomas Andraschko > >> Hi Leo, >> >> By default all the code in UIComponentBase is already in place, so >>> if all components extend from UIComponentBase everything will work just >>> fine >> >> >> cool, perfect! >> >> What about Behaviors or ActionListeners like: >> >> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java >> >> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java >> >> Will they work correctly? >> > > Yes, because the related variables are stored into the state, so if > they change, saveState(...) will return non null and in the worst case the > component will be replaced with a new one. > > The ideal is the attached objects (Collector) implements > PartialStateHolder instead StateHolder. The reason is the hack involves > save the state when markInitialState(...) was called and when a hard reset > is done, reuse that information and restore the state of the component or > attached object like it was when the view was built by first time. But if > that is not done, the algorithm just replace the component with a new one > and problem solved. > > The tricky part are those variables that are not part of the state buy > plays some role, because there is no way to know they are there. For > example the dataModelMap in UIData, but the examples out there are very > few. > > >> All other components in PrimeFaces just use the StateHelper. So it >> should be fine. >> >> > If saveState(...) is overriden, there is a chance that some additional > lines are required. > > Note we still have a lot of work to do, but the evidence we have > suggest we should at least give another try and see what happens. > > regards, > > Leonardo Uribe > > >> Regards, >> Thomas >> >> >> > >>> >> >
[jira] [Resolved] (MYFACES-3831) CacheELFaceletCacheImpl is not storing the compiled template (only when "alwaysRecompile" is enabled)
[ https://issues.apache.org/jira/browse/MYFACES-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3831. - Resolution: Fixed Fix Version/s: 2.2.0 2.1.14 > CacheELFaceletCacheImpl is not storing the compiled template (only when > "alwaysRecompile" is enabled) > - > > Key: MYFACES-3831 > URL: https://issues.apache.org/jira/browse/MYFACES-3831 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314, JSR-344 >Affects Versions: 2.1.13, 2.2.0-beta >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.1.14, 2.2.0 > > > Doing some tests over the code, I found a bug inside CacheELFaceletCacheImpl > . In few words, when "alwaysRecompile" is activated, the compiled facelet is > not stored properly, but only when it belongs to a template. > The bug was really hard to track down, because everything works well, so I > didn't see any symptom. But later on, I checked some performance measurements > over the code, finding some inconsistencies with previous measurements done > long time ago. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Hi Thomas What I can do is use an attribute to mark the view as poolable or not poolable. The annotation code must be done outside core. regards, Leonardo 2013/12/7 Thomas Andraschko > Leo, one question: > Is it possible to mark a view as "poolable" via code? > We configure all our views via typesafe view config from CODI/DS > > > > 2013/12/4 Thomas Andraschko > >> Looks fine for me! >> >> >> 2013/12/3 Leonardo Uribe >> >>> Hi >>> >>> I have been thinking about how to define the configuration for the view >>> pool. The idea is add the following new web config parameters: >>> >>> org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in >>> the app, by default false) >>> org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE (the number of views stored >>> in the pool per key) >>> org.apache.myfaces.VIEW_POOL_MAX_DYNAMIC_PARTIAL_LIMIT (the number of >>> dyn views that can be used as partial) >>> org.apache.myfaces.VIEW_POOL_ENTRY_MODE (weak, soft) >>> org.apache.myfaces.VIEW_POOL_DEFERRED_NAVIGATION (reuse views that are >>> navigated using default algorithm (increase reusal but it uses a hack that >>> does not follow jsf spec) ) >>> >>> And include this possible extension in faces-config.xml: >>> >>> >>> >>> /* >>> >>> org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE >>> 5 >>> >>> >>> >>> >>> The idea is allow users to enable the view pool only for a part of the >>> application using and override some specific view pool >>> parameters. The idea is there are parts of the application that are used >>> quite intensively and others that are not frequently visited. >>> >>> Suggestions are welcome. >>> >>> regards, >>> >>> Leonardo Uribe >>> >>> >>> >>> 2013/11/25 Martin Kočí >>> Hi, +1 for this feature in core 2.2. Regards, Kocicak 2013/11/24 Thomas Andraschko > Perfect. Thanks for Info. > > So +1 from my side. > > > 2013/11/24 Leonardo Uribe > >> Hi >> >> 2013/11/24 Thomas Andraschko >> >>> Hi Leo, >>> >>> By default all the code in UIComponentBase is already in place, so if all components extend from UIComponentBase everything will work just fine >>> >>> >>> cool, perfect! >>> >>> What about Behaviors or ActionListeners like: >>> >>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java >>> >>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java >>> >>> Will they work correctly? >>> >> >> Yes, because the related variables are stored into the state, so if >> they change, saveState(...) will return non null and in the worst case >> the >> component will be replaced with a new one. >> >> The ideal is the attached objects (Collector) implements >> PartialStateHolder instead StateHolder. The reason is the hack involves >> save the state when markInitialState(...) was called and when a hard >> reset >> is done, reuse that information and restore the state of the component or >> attached object like it was when the view was built by first time. But if >> that is not done, the algorithm just replace the component with a new one >> and problem solved. >> >> The tricky part are those variables that are not part of the state >> buy plays some role, because there is no way to know they are there. For >> example the dataModelMap in UIData, but the examples out there are very >> few. >> >> >>> All other components in PrimeFaces just use the StateHelper. So it >>> should be fine. >>> >>> >> If saveState(...) is overriden, there is a chance that some >> additional lines are required. >> >> Note we still have a lot of work to do, but the evidence we have >> suggest we should at least give another try and see what happens. >> >> regards, >> >> Leonardo Uribe >> >> >>> Regards, >>> Thomas >>> >>> >>> >> > >>> >> >
